NORMA ISO Resumen

Transcripción

1 NORMA ISO Resumen

2 RESUMEN DE NORMA ISO INFORMACIÓN GEOGRÁFICA - SERVICIOS Esta norma internacional provee un marco de trabajo para aquellos que proyecten crear aplicaciones que permitan a los usuarios acceder y procesar datos geográficos procedentes de diversas fuentes a través de la identificación y definición de la interfaz, que se utilizan para la información geográfica, así como la definición de las relaciones de los Modelos de Entorno de Sistemas Abiertos. Está basada en el Modelo de Referencia del Procesamiento Distribuido Abierto (RM-ODP) (ISO/IEC 10746). Define la interfaz de servicio, que permite que aplicaciones con diferentes niveles de funcionalidad accedan a la información geográfica y puedan utilizarla, y las interfaces para acceder a estos servicios especializados, las que deben estar estandarizadas. Destaca la importancia de la estandarización de los interfaces de estos servicios para admitir la interoperabilidad entre diversos productos, y permitir que el trabajo se integre con propuestas que se desarrollen en el mundo de la tecnología de la información. Desarrolla la arquitectura de servicios geográficos para lograr un entorno de trabajo adecuado para el desarrollo coordinado de servicios específicos, la interoperabilidad entre servicios a través del uso de estándares de interfaces, la formación de catálogos de servicio a través de la definición de metadatos de servicio, permitiendo el uso de un servicio de un proveedor con datos de otro proveedor. La arquitectura de esta norma se basa en un modelo multicapas, a la que define como un conjunto de componentes, conexiones y topologías definida a través de diversos de puntos de vista, tales como el computacional, que considera los patrones de interacción entre componentes (servicios) del sistema, descrito a través de sus interfaces; la información, que aborda la semántica de la información y los procesos de información; el técnico, que trata el diseño de los aspectos orientados a la distribución, es decir, la infraestructura requerida para soportar la distribución; y el tecnológico, que describe la implementación del sistema RM-ODP en términos de una configuración de objetos tecnológicos que representan los componentes hardware y software de la implementación. Como modelo de referencia se utiliza una arquitectura lógica, que es un conjunto de servicios y sus interfaces asociadas, que son representados en el sistema con cuatro capas adaptables a diferentes arquitecturas físicas, a las que considera como un conjunto de componentes, que se ubican en recursos hardware o nodos, e interfaces asociadas que implementan los servicios. Noviembre de 2009 i

3 Interpretación de lo establecido en NORMA ISO Servicios

4 ISO Información Geográfica Servicios Contenido ÍNDICE Información Geográfica - Servicios 5 1. Alcance 5 2. Conformidad Referencias Normativas Términos y definiciones. 5 Página 4.1. Servicio Interfaz Operación Interoperabilidad Encadenamiento de servicios Flujo de trabajo Punto de vista Punto de vista empresarial Punto de vista de la información Punto de vista de la computación Punto de vista de la ingeniería Punto de vista de la tecnología Transparencia de la distribución Términos abreviados 7 6. Visión general de la arquitectura de servicios geográficos Propósito y justificación Modelo de referencia de interoperabilidad basado en ISO RM-ODP Abstracción de un servicio Interoperabilidad Uso de otras normas de información geográfica en la especificación de servicios Patrones de arquitectura Punto de vista de la computación: una base para el encadenamiento de servicios Componente e interoperabilidad de servicios y el punto de vista computacional Servicio, interfaces y operaciones Encadenamiento de servicios Introducción al encadenamiento de servicios Anatomía de una cadena de servicios.. 18 Noviembre de

5 Contenido Página Carpeta para organizar servicios Servicios que permiten el encadenamiento de servicios Patrones de arquitectura para encadenamiento de servicios Variaciones sobre los patrones de encadenamiento Metadatos de servicio Introducción Diagrama de clases principales de metadatos de servicio Diccionario de datos para metadatos de servicios geográficos Instancia de servicio de un tipo desconocido Arquitectura de servicio simple Punto de vista de la información: una base para la interoperabilidad semántica Interoperabilidad del modelo de información y el punto de vista de la información Entorno de sistemas abiertos extendidos para servicios geográficos Taxonomía de servicios geográficos Requisitos de la taxonomía de servicios geográficos Servicios geográficos de interacción humana Servicios de gestión de modelo/información geográfica Servicios de gestión de flujos de trabajo/tareas geográficas Servicios geográficos de procesamiento Servicios geográficos de comunicación Servicios geográficos de gestión de sistemas Las series ISO de normas internacionales en la taxonomía de servicios geográficos Validación de encadenamiento de servicios geográficos Carpeta para organizar servicios (SOF) Introducción SOF para la explotación de imágenes SOF para la fusión de datos geográficos Punto de vista de la ingeniería. Una base para la distribución Transparencia de la distribución y el punto de vista de la ingeniería Componentes distribuidos usando un modelo de arquitectura multicapa Punto de vista de la tecnología. Una base para la interoperabilidad cruzada entre plataformas Interoperabilidad de la infraestructura y el punto de vista de la tecnología Necesidad de múltiples especificaciones específicas de la plataforma Conformidad entre especificaciones de servicio específicas de plataforma e independiente de plataforma De especificaciones independientes de plataforma a específicos de una plataforma.. 58 Noviembre de

6 Contenido Página Anexo A (Normativo) Conformidad.. 60 A.1. Requisitos de conformidad.. 60 A.2. Módulo de pruebas de la arquitectura de servicio.. 60 A.2.1. Definición de tipos de servicios geográficos 60 A.2.2. Cadena de servicios. 60 A.2.3. Patrones de encadenamiento de servicio 61 A.2.4. Arquitectura de servicios simple 61 A.3. Módulo de prueba de la especificación de servicios.. 62 A.3.1. Introducción.. 62 A.3.2. Especificaciones de servicio independiente de plataforma.. 62 A.3.3. Especificaciones de servicio de específica a una plataforma.. 63 A.3.4. Implementaciones de servicio específicos de una plataforma 64 Anexo B (Informativo) Ejemplos de escenarios de uso.. 65 B.1. Ejemplo 1: Encadenamiento de servicios para datos de teledetección.. 65 B.1.1. Resumen 65 B.1.2. Precondiciones.. 65 B.1.3. Pasos detallados B.1.4. Poscondiciones. 66 B.1.5. Grafo dirigido acíclico de la cadena de servicios. 66 B.2. Ejemplo 2: Servicios de rutas B.2.1. Resumen 67 B.2.2. Precondición.. 67 B.2.3. Pasos detallados 67 Anexo C (Normativo) Diccionario de datos para metadatos de servicios geográficos 69 C.1. Visión general del diccionario de datos 69 C.1.1. Introducción C.1.2. Atributo nombre/rol 69 C.1.3. Definición C.1.4. Obligación/condición. 69 C.1.5. Ocurrencia máxima 70 C.1.6. Tipo de datos. 70 C.1.7. Clases de atributos o clases objetivos de rol 70 C.1.8. Prefijos para los nombres. 70 C.2. Diccionarios de datos de metadatos 71 C.2.1. Diccionario de datos para MD_Identification 71 C.2.2. Diccionario de datos para SV_ServiceIdentification. 71 C.2.3. Diccionario de datos para SV_OperationMetadata.. 72 C.2.4. Diccionario de datos para SV_ServiceProvider 73 C.2.5. Diccionario de datos para MD_DataIdentification 74 Noviembre de

7 Contenido Página C.2.6. Diccionario de datos para SV_OperationChainMetadata 74 C.2.7. Diccionario de datos para SV_Parameter 74 Anexo D (Informativo) Traducción a plataformas de computación distribuidas 75 D.1. De especificaciones independientes de plataforma a específicos de plataforma. 75 D.2. Constructores UML usados en la serie de Normas Internacionales ISO de los estándares internacionales. 78 D.3. Modelo tecnológico independiente de plataforma D.4. Traducción a especificaciones de servicio específicos de CORBA 80 D.5. Traducción a especificaciones de servicio específicos de MS COM. 82 D.6. Traducción a especificaciones de servicio específicos J2EE/EJB. 83 D.7. Traducción a especificaciones de servicio específicos EXPRESS/SDAI 85 D.8. Traducción a especificaciones de servicio específicos SQL Bibliografía 87 Noviembre de

8 Información Geográfica: ISO Servicios 1. Alcance Esta norma internacional es aplicable a la identificación y definición de los patrones de arquitectura para interfaces de servicio usados sobre información geográfica y la definición de las relaciones con el modelo de Entorno de Sistemas Abiertos. Presenta una taxonomía de servicios geográficos y una lista de ejemplos de servicios geográficos ubicada en la taxonomía de servicios. Esta norma demuestra cómo crear una especificación de servicios independiente de la plataforma, y cómo emanar especificaciones de servicios sobre plataformas específicas; ofreciendo una guía para la selección y especificación de servicios geográficos, tanto desde una perspectiva independiente de la plataforma como de plataforma específica. 2. Conformidad Cualquier producto que pretenda concordar con esta norma internacional debe cumplir con todos los requisitos descritos en el conjunto de pruebas genéricas dado en el Anexo A. Nota: La definición de un conjunto de pruebas genéricas se puede encontrar en la Norma ISO Referencias Normativas Son indispensables para la aplicación de esta norma, las que se indican a continuación. Para las referencias con fecha, sólo se aplica la edición citada, mientras que para las referencias sin fecha, se aplica la última edición de la norma (incluyendo cualquier modificación). ISO/IEC :1998 Tecnología de la información. Procesamiento distribuido abierto. Modelo de referencia: visión general. Parte 1. ISO/IEC :1996 Tecnología de la información. Procesamiento distribuido abierto. Modelo de referencia: fundamentos. ISO/IEC TR 14252:1996 Tecnología de la información. Guía del POSIX entorno de sistemas abiertos (OSE Open System Environment). ISO/TS 19103:.1) Información Geográfica. Lenguaje del esquema conceptual. ISO 19115:2003 Información geográfica. Metadatos. 4. Términos y definiciones A los fines de este documento, se aplican los siguientes términos y definiciones Servicio Parte distinguible de la funcionalidad que una entidad proporciona a través de sus interfaces (4.2.). Noviembre de

9 (Adaptado de ISO/IEC TR 14252) Nota: Véase el apartado 7.2 para una discusión de servicio Interfaz Conjunto de operaciones con su denominación (4.3.) que caracterizan el comportamiento de una entidad. Nota: Véase el apartado 7.2 para una discusión de interfaz Operación Especificación de una transformación o consulta que puede pedirse a un objeto que ejecute. Nota 1: Una operación tiene un nombre y una lista de parámetros. Nota 2: Véase el apartado 7.2 para una discusión de operación Interoperabilidad Capacidad para comunicarse, ejecutar programas, o transferir datos entre varias unidades funcionales de forma que se requiera del usuario poco o ningún conocimiento de las características únicas de esas unidades. (ISO/IEC ) 4.5. Encadenamiento de servicios Secuencia de servicios (4.1) donde, por cada par de servicios adyacentes, es necesaria la ocurrencia de la primera acción para la ocurrencia de la segunda Flujo de trabajo Automatización de un proceso de negocio, total o parcialmente, por el que se pasan los documentos, informaciones y tareas de un participante a otro por acciones, en conformidad con un conjunto de reglas de procesamiento Punto de vista <De un sistema> forma de abstracción que se realiza usando un conjunto seleccionado de conceptos arquitectónicos y reglas de estructuración, para centrarse en algunos asuntos determinados dentro de un sistema. (ISO/IEC ) 4.8. Punto de vista empresarial Punto de vista (4.7) de un sistema ODP (Open Distributed Processing) y su entorno que se centraliza en el propósito, campo de aplicación y políticas para ese sistema. Noviembre de

10 4.9. Punto de vista de la información Punto de vista (4.7) de un sistema ODP y su entorno que se enfoca en la semántica de la información y el procesamiento de la información Punto de vista de la computación Punto de vista (4.7) de un sistema y su entorno que permite la distribución a través de la descomposición funcional del sistema en objetos que interactúan con interfaces (4.2) Punto de vista de la ingeniería Punto de vista (4.7) de un sistema ODP y su entorno dirigido a los mecanismos y funciones requeridas para soportar la interacción distribuida entre los objetos del sistema Punto de vista de la tecnología Punto de vista (4.7) de un sistema ODP y su entorno que se centra en la elección de la tecnología del sistema Transparencia de la distribución Propiedad de ocultar a un usuario particular el comportamiento potencial de algunas partes de un sistema distribuido. (ISO/IEC ) Nota: La transparencia de la distribución permite ocultar a las aplicaciones, la complejidad asociada con la distribución de sistemas, cuando es irrelevante para las mismas. 5. Términos abreviados ADO ActiveX Data Objects (Objetos de Datos ActiveX) API Application Programming Interface (Interfaz de Programación de Aplicaciones) CCM Client Configuration Manager (Gestión de Configuración de Clientes) COM Component Object Model (Modelo de Objetos de Componentes) CORBA Common Object Request Broker Architecture (Arquitectura de Agentes de Peticiones de Objetos Comunes) CICS Customer Information Control System (Sistema de Control de Información al Cliente) DAG Directed Acyclic Graph (Grafo Acíclico Directo) DCOM Distributed Component Object Model (Modelo de Objetos de Componentes Distribuidos) DCP Distributed Computing Platform (Plataforma de Computación Distribuida) DEM Digital Elevation Model (Modelo de Elevación del Terreno) DNA Distributed InterNet Applications (Aplicaciones de Internet Distribuidas) Noviembre de

11 EDOC Enterprise Distributed Object Computing (Computación de Objetos de Negocio Distribuidos) DTD Document type definitions (Documento de Definiciones de Tipos) EJB Enterprise Java Beans (Componentes de Negocio Java) EOSE Extended Open Systems Environment Model (Modelo Extendido de Entorno de Sistemas Abiertos) ERP Enterprise Resource Planning (Plan de Recursos de Negocio) GIOP General Inter-ORB Protocol (Protocolo Inter-ORB General) GUI Graphic User Interface (Interfaz de Usuario Gráfico) HIS Information Technology Human Interaction Service (Servicio de Interacción Humana de la Tecnología de la Información) HTI Human Technology Interface (Interfaz Tecnológico Humano) HTML Hypertext markup language (Lenguaje de Marcas de Hipertexto) HTTP Hypertext Transfer Protocol (Protocolo de Transferencia de Hipertexto) IDL Interface Definition Language (Lenguaje de Definición de Interfaces) IIOP Internet Inter-ORB Protocol (Protocolo InterORB de Internet) IIS Internet Information Server (Servidor de Información de Internet) IT Information Technology (TI Tecnología de la información) J2EE Java 2 Enterprise Edition with EJB (EJB con Edición de Java 2 Empresarial) JDBC Java Data Base Connectivity (Conectividad a Base de Datos Java) JSP Java Server Pages (Páginas de Servidor Java) JINI Sun s open architecture that enables developers to create network-centric services (Arquitectura abierta de Sun que permite a los desarrolladores crear servicios centrados en redes) JNDI Java Naming and Directory Interface (Interfaz Java de Directorio y Nombres) JTA Java Connector Architecture (Arquitectura de Conectores Java) JTS Java Transaction Service (Servicio Java de Transacciones) MAPI Messaging Application Programming Interface (Interfaz de Programación de Aplicaciones de Mensajería) MS MTS Microsoft Transaction Server (Servidor de Transacciones de Microsoft) MSMQ Microsoft Message Queuing (Cola de Mensajes de Microsoft) MTS Microsoft Transaction Server (Servidor de Transacciones de Microsoft) OCL Object Constraint Language (Lenguaje de Restricciones sobre Objetos) ODBC Open Database Connectivity (Conectividad a Bases de Datos Abiertas) ODMG Object Database Management Group (Grupo de Gestión de Bases de Datos de Objetos) Noviembre de

12 ODP Open Distributed Processing (see RM-ODP) (Procesamiento Distribuido Abierto. véase RM-ODP-) OGC Open GIS Consortium (Consorcio de GIS Abierto) OMG Object Management Group (Grupo de Gestión de Objetos) OODB Object-oriented database (Base de Datos Orientada a Objetos) ORB Object Request Broker (Agente de Petición de Objetos) OSE Open Systems Environment (Entorno de Sistemas Abiertos) RMI Remote Method Invocation (Invocación de Métodos Remotos) RM-ODP Reference Model of Open Distributed Processing (ISO/IEC 10746) (Modelo de Referencia de Procesamiento Distribuido Abierto) RPC Remote Procedure Call (Llamada a Procedimiento Remoto) SDAI Standard Data Access Interface (ISO ) (Interfaz de Acceso a Datos Estándares) SOAP Simple Object Access Protocol (Protocolo de Acceso a Objetos Simples) SOF Service Organizer Folder (Carpeta para Organizar Servicios) SQL Structured Query Language (Lenguaje de Consulta Estructurado) UML Unified Modelling Language (Lenguaje de Modelado Unificado) URI Uniform Resource Identifier (Identificador de Recursos Único) XML Extensible Markup Language (Lenguaje de Marcas Extensible) XML RDF XML Resource Description Framework (Entorno de Descripción de Recursos XML) XSLT XML Stylesheet Language Transformations (Transformaciones del Lenguaje de Hoja de Estilos XML) 6. Visión general de la arquitectura de servicios geográficos 6.1. Propósito y justificación La definición de servicios incluye para el acceso y uso de la información geográfica, un conjunto de aplicaciones con diferentes niveles de funcionalidad. Mientras que los servicios especializados permanecerán, adecuadamente, en el área de los productos propietarios, la normalización de las interfaces de esos servicios permite la interoperabilidad entre productos propietarios. Los sistemas de información geográfica y los desarrolladores de aplicaciones usarán estas normas para proveer servicios generales y especializados que puedan ser usados para todo tipo de información geográfica. El enfoque de esta norma internacional se integra con la tendencia que se está desarrollando dentro del mundo más general de la tecnología de la información. Noviembre de

13 La arquitectura de servicios geográficos especificada en esta norma internacional, se ha desarrollado para lograr los siguientes objetivos: proveer de un entorno de trabajo abstracto que permita el desarrollo coordinado de servicios específicos; disponer de servicios de datos interoperables a través de la normalización de interfaces; soportar el desarrollo de catálogos de servicios a través de la definición de metadatos de servicio; permitir la separación de instancias de datos e instancias de servicio; permitir el uso de un servicio de un proveedor y los datos de otro proveedor; definir un entorno de trabajo abstracto que pueda ser implementado de múltiples formas. Esta norma internacional extiende el modelo de referencia de arquitectura establecido en la Norma ISO 19101, en el que se define un modelo de entorno de sistemas abierto extendido (EOSE) para servicios geográficos Modelo de referencia de interoperabilidad basado en ISO RM-ODP Esta norma internacional se ha desarrollado tomando como base el enfoque de arquitectura de sistemas para el diseño de sistemas conocido como Modelo de Referencia de Procesamiento Distribuido Abierto (véase la Norma ISO/IEC 10746). La arquitectura se define como un conjunto de componentes, conexiones y topología especificadas a través de una serie de vistas. La infraestructura geográfica descrita por esta norma internacional tendrá múltiples usuarios, creadores de aplicaciones, operadores y revisores. Cada grupo verá el sistema desde su propia perspectiva. El propósito de la arquitectura es proporcionar una descripción del sistema desde múltiples puntos de vista. También ayuda a asegurar que cada vista será coherente con los requerimientos y con las otras vistas. La Tabla 1 muestra los puntos de vistas RM-ODP que se utilizan en esta Norma internacional. Noviembre de

14 Tabla 1. Uso de los puntos de vista RM-ODP en esta norma internacional Nombre de puntos de vista Punto de vista empresarial Punto de vista de la computación Punto de vista de la información Punto de vista de la ingeniería Punto de vista de la tecnología Definición de punto de vista RMODP (ISO/IEC :1998) Punto de vista de un sistema ODP y su entorno que se enfoca en el propósito, el campo de aplicación y políticas para ese sistema Punto de vista de un sistema ODP y su entorno que permite la distribución a través de la descomposición funcional del sistema en objetos que interactúan con interfaces Punto de vista de un sistema ODP y su entorno que se centraliza en la semántica de la información y el procesamiento de la información Punto de vista de un sistema ODP y su entorno que se centra en los mecanismos y funciones requeridas para soportar interacción distribuida entre los objetos del sistema Punto de vista de un sistema ODP y su entorno que se concentra en la elección de la tecnología del sistema Como se trata el punto de vista en esta norma internacional Esto está disponible en otras partes de las series de Normas ISO 19100, por ejemplo, el modelo de referencia (ISO 19101) Véase el apartado 7, punto de vista de la computación Véase el apartado 8, punto de vista de la información Véase el apartado 9, punto de vista de la ingeniería Véase el apartado 10, punto de vista de la tecnología; también es tratado por las especificaciones de servicio de plataforma específica El punto de vista empresarial se ocupa del propósito, campo de aplicación y políticas de una empresa o negocio y cómo se relacionan con un sistema específico o servicio. Una especificación empresarial de un servicio, es un modelo de ese servicio y el entorno con el que el servicio interactúa. Cubre el papel del servicio en el negocio y los roles de las personas y políticas de negocio relacionadas con el servicio. El punto de vista de la computación está enfocado a la interacción de patrones entre los componentes (servicios) del sistema, descrito a través de sus interfaces. Una especificación de la computación de un servicio, es un modelo de la interfaz del servicio vista desde el cliente, y el conjunto potencial de otros servicios que este servicio requiere que estén disponibles, describiendo la interacción entre servicios como fuentes y puntos de información. El punto de vista de la información se centra en la semántica de la información y el procesamiento de la misma. Una especificación de la información de un sistema ODP es un modelo de la información que contiene y de los procesamientos de la información que se desarrollan. El punto de vista de la ingeniería trata el diseño de los aspectos orientados a la distribución, o sea la infraestructura requerida para soportar la distribución. Una Noviembre de

15 especificación de la ingeniería de un sistema ODP define una infraestructura de red de computación que soporta la estructura del sistema definida en la especificación de la computación y que proporciona la transparencia de la distribución que se define. ODP define las siguientes transparencias de distribución: acceso, fallo, localización, migración, reubicación, duplicación, persistencia y transacción. La seguridad también puede ser un mecanismo. El punto de vista de la tecnología describe la implementación del sistema ODP en términos de una configuración de los objetos tecnológicos que representan los componentes físicos y lógicos del producto. Está restringido por los costos y la disponibilidad de los objetos tecnológicos (productos físicos y lógicos) que satisfagan esta especificación. Estos pueden cumplir normas específicas de una plataforma que son, de hecho, plantillas de objetos tecnológicos. En lo referente a los puntos de vista computacional y de información, los capítulos de esta norma internacional, proporcionan los enfoques específicos que deben ser seguidos para definir servicios de información geográfica. Para los puntos de vistas de la ingeniería y la tecnología, esta norma internacional define cómo un determinado servicio debe ser traducido a una implementación tecnológica, tal como SQL-3/ODBC, ODMG, CORBA, DCOM/OLE, Internet o tecnologías similares Abstracción de un servicio Esta norma internacional define el enfoque que debe usarse para definir servicios en la serie de Normas ISO La Figura 1 define la relación entre los diferentes tipos de especificaciones de servicio. SV_ServiceSpecification define los servicios sin hacer referencia al tipo de especificación o a su implementación. Un SV_PlatformNeutralServiceSpecification provee una definición abstracta de un tipo de servicio específico, pero no especifica la implementación del servicio. Se dan los tipos de servicio en la taxonomía de servicios geográficos del apartado 8.3. SV_PlatformSpecificService Specification define la implementación de un tipo de servicio específico. Puede haber múltiples especificaciones de una plataforma específica para una única especificación independiente de la plataforma. SV_Service es una implementación de un servicio. Los requisitos para estas especificaciones son tratados en esta norma internacional, en particular en el apartado 10. Noviembre de

16 Figura 1. Especificación de servicio abstracto e implementado 6.4. Interoperabilidad La interoperabilidad es la capacidad de comunicar, ejecutar programas, o transferir datos entre varias unidades funcionales de forma que se requiera por parte del usuario poco o ningún conocimiento de las características únicas de esas entidades. Dos componentes X e Y (véase la Figura 2) pueden interoperar (ser interoperables) si X puede enviar peticiones de servicio R a Y, basadas en un entendimiento mutuo de R por parte de X y de Y, y si Y puede, de igual forma, devolver respuestas S, mutuamente entendidas, a X. Figura 2. Interoperabilidad Noviembre de

17 Esto significa que dos sistemas interoperables pueden interactuar conjuntamente para ejecutar tareas. Para el dominio geográfico, se aplica la siguiente descripción del término interoperabilidad geográfica : Interoperabilidad geográfica es la capacidad de los sistemas de información de 1) intercambiar libremente toda clase de información espacial sobre la tierra y sobre los objetos y fenómenos sobre y por debajo de la superficie terrestre; 2) cooperativamente, sobre redes, ejecutar aplicaciones capaces de manipular tal información. La abstracción del punto de vista ODP proporciona un marco de trabajo para describir un sistema en diferentes niveles de abstracción. En esta norma internacional, la interoperabilidad es vista en términos de los diferentes niveles de abstracción proporcionados por RM-ODP. Determina cómo puede ser soportada la interoperabilidad sintáctica y semántica de los metadatos geográficos y de los datos geográficos, desde diferentes puntos de vista. Cuando dos organizaciones diferentes han desarrollado independientemente sistemas distribuidos, cada uno puede ser descrito de acuerdo a los puntos de vista RM- ODP, y se puede discutir la interoperabilidad entre los sistemas con respecto a cada uno de los cinco puntos de vista RM-ODP. Por cada aspecto de la interoperabilidad, se hace una distinción entre interoperabilidad sintáctica e interoperabilidad semántica. La interoperabilidad sintáctica asegura que hay una conexión técnica, lo que quiere decir que los datos pueden ser transferidos entre sistemas. La interoperabilidad semántica asegura que el contenido es entendido de la misma forma por ambos sistemas, incluyendo a las personas que interactúan con el sistema en un contexto dado Uso de otras normas de información geográfica en la especificación de servicios Una especificación de servicio debe incluir los modelos de información relevantes para las normas de información geográficas apropiados de la serie de Normas ISO Debe usarse el modelo UML correspondiente en la definición de las interfaces de servicio que sean apropiadas Patrones de arquitectura Un patrón de arquitectura expresa una organización estructural fundamental o esquema para aplicaciones de servicios. Define un conjunto de servicios, especifica sus responsabilidades, e incluye las reglas y guías para la organización de las relaciones entre ellos. Los servicios, implementados por clases y objetos, pueden usar patrones de diseño pero este nivel de detalle está fuera del objeto y campo de aplicación de esta norma internacional. Noviembre de

18 La Tabla 2 ofrece una lista de elementos de un patrón. Deben usarse estos elementos cuando se definen patrones de arquitectura especificados en esta norma internacional. Tabla 2. Elementos de un patrón Elementos de un patrón Nombre Problema Contexto Obligaciones Estructuras Descripción del elemento El nombre es una palabra o frase corta significativa que describe el patrón. El nombre es muy importante, ya que se usa para reducir la comunicación en general. Pueden proveerse alias o sinónimos. Es la declaración del problema que describe las intenciones, propósitos y objetivos que se quieren alcanzar dentro del contexto y las consideraciones dadas. Frecuentemente las consideraciones se oponen a esos objetivos viceversa. El contexto define las precondiciones bajo las cuales el problema y su solución parecen repetirse, y para las que la solución es deseable. Define la aplicabilidad del patrón. Puede considerarse como configuración inicial del sistema antes de que se aplique el patrón. Las obligaciones son detalles que tienen que ser valorados para alcanzar la mejor solución. Las obligaciones definen la clase de compensaciones que se tienen que tener en cuenta ante la presencia de tensiones o disonancias creadas. La estructura define las relaciones estáticas y las reglas dinámicas que describen cómo se consigue la salida deseada. La descripción de la estructura se realiza a través de los diagramas de colaboración. 7. Punto de vista de la computación: una base para el encadenamiento de servicios 7.1. Componente e interoperabilidad de servicios y el punto de vista computacional El punto de vista de la computación trata de describir las entidades de un sistema distribuido independientemente de su implementación y el contenido semántico describe los patrones de interacción entre las entidades y sus interfaces. Para ser capaz de interoperar desde el punto de vista de la computación, dos sistemas tienen que ser interoperables a nivel de servicio y de interfaz. Dos sistemas son interoperables a nivel de servicio y de interfaz si están de acuerdo en el conjunto de servicios ofrecidos por las entidades de los dos sistemas y las interfaces de esas entidades. Si se definen interfaces normalizadas, la entidad de un sistema debe ser capaz de solicitar servicios de las entidades del otro sistema. El apartado del punto de vista computacional ofrece lo siguiente: define los conceptos de servicios, interfaces y operaciones y las relaciones entre estos conceptos; provee una aproximación a la distribución física de servicios usando una arquitectura con varias capas; define un modelo para combinar servicios en series dependientes para realizar tareas más complejas, es decir, encadenamiento de servicios; Noviembre de

19 define un modelo de metadatos de servicio para soportar la localización de servicios a través de un catálogo de servicios Servicio, interfaces y operaciones En este apartado se proveen las definiciones y relaciones de varios términos, que son muy usados en esta norma internacional: servicio: parte distinguible de la funcionalidad que una entidad proporciona a través de interfaces; interfaz: conjunto nombrado de operaciones que caracteriza el comportamiento de una entidad; operación: especificación de una transformación o consulta que puede pedirse a un objeto que ejecute. Tiene un nombre y una lista de parámetros. Estos términos se relacionan entre sí como se puede observar en la Figura 3, en la cual se muestra que los servicios son especificados por un conjunto de interfaces que son un conjunto de operaciones. Las interfaces son implementadas como puertos que ofrecen servicios a disposición de los usuarios. Figura 3. Relaciones de la definición de servicios La agregación de interfaces en un servicio que debe hacerse con el propósito de definir funcionalidad útil para los usuarios. Noviembre de

20 En este contexto, los usuarios son tanto aplicaciones como personas. Un servicio provee funcionalidad que añade valor; el valor se hace evidente al usuario que ha requerido el servicio. La agregación de operaciones en una interfaz, y la definición de interfaz, debe realizarse con el propósito de conseguir la reusabilidad de las aplicaciones. Las interfaces deben definirse para que puedan ser reusables por múltiples tipos de servicios. La sintaxis de una interfaz puede reutilizarse con múltiples servicios con semánticas diferentes. Pueden agregarse servicios de múltiples tipos; los tipos de servicios deben definirse de forma consistente con la taxonomía de servicios del apartado 8.3. Cuando un servicio proporciona una funcionalidad que va más allá de la de una única categoría de la taxonomía de servicios, debe considerarse como un servicio agregado. El encadenamiento de servicios resulta de la agregación de servicios como se define en el apartado Las interfaces son especificaciones abstractas separadas del desarrollo concreto o la asociación con formatos de datos. La especificación de una interfaz debe incluir una porción estática que involucra la definición de operaciones. La especificación de una interfaz debe incluir una porción dinámica que contiene restricciones a la hora de solicitar las operaciones. Una implementación de una interfaz es un puerto. La implementación incluye la construcción de una especificación de una plataforma determinada y un método para identificar el servicio, por ejemplo, una dirección. Una implementación de un servicio puede estar asociada con un conjunto de datos específicos o puede ser un servicio que puede usarse para operar con múltiples conjuntos de datos no especificados. El primer caso es conocido como un servicio fuertemente acoplado, mientras que el segundo caso se conoce como un servicio débilmente acoplado (véase el apartado 7.4.1). Las interfaces se definen a través de operaciones. Una operación especifica una transformación del estado del objeto en cuestión o una consulta que devuelve un valor al que realiza la llamada de la operación. Una operación debe ser una descripción abstracta de una acción que el interfaz soporta. Las operaciones contienen parámetros Encadenamiento de servicios Introducción al encadenamiento de servicios El apartado 7.3 define un modelo para la combinación de servicio en una serie dependiente que permita realizar tareas más complejas. Trata las cuestiones relativas a la sintáctica del encadenamiento de servicios, por ejemplo, la estructura de datos de una cadena. Los aspectos semánticos asociados con el encadenamiento de servicios son Noviembre de

21 tratados en el apartado 8.6, por ejemplo, una cadena determinada produce un resultado válido? En el Anexo B se proporcionan ejemplos de encadenamientos de servicios. Esta norma internacional permite a los usuarios combinar datos y servicios de formas no predefinidas por los proveedores de datos y servicios. Este nivel de interoperabilidad de datos y servicios se conseguirá por etapas. En primer lugar, los catálogos de servicios mantendrán entradas con fuertes conexiones entre datos y servicios. Finalmente la infraestructura estará disponible para que el usuario determine qué datos pueden ser usados a través de un servicio débilmente acoplado. Esta capacidad estará disponible a través de la infraestructura en un mayor dominio de la IT. Basado en la definición ODP de cadena, una cadena de servicios se define como una secuencia de servicios donde, por cada par de servicios adyacentes, es necesaria la ocurrencia de la primera acción para la ocurrencia de la segunda acción Anatomía de una cadena de servicios Cadenas como grafos dirigidos La acción de crear la entrada de un servicio dependiendo de otro servicio lleva a tratar las cadenas de servicios como grafos dirigidos, donde cada servicio es un nodo del grafo, y las referencias a interacciones entre servicios forman los arcos. En algunos casos, la estructura del grafo dirigido está implícita, mientras que en otros casos, es necesario crear la noción de un grafo de procesamiento explícito y permitir que tales grafos sean considerados como entidades por sí mismas. La representación explícita de una cadena de servicios permite que la cadena sea representada visualmente y pasada a un servicio de ejecución de cadenas, por ejemplo, un servicio de flujo de trabajo. Un nodo de un grafo dirigido es una representación de un servicio. Cuando explícitamente forma parte de una estructura de datos, un nodo de servicio contiene dos tipos de información, de parámetros y fuentes; los parámetros de un nodo de servicios proporcionan las configuraciones del servicio para una cadena particular en la cual se está usando la clase del servicio. Las fuentes de un nodo de servicio indican las fuentes de entrada de datos al nodo. Los arcos de un grafo dirigido que representa una cadena de servicios, pueden ser de varios tipos. Estos tipos de arcos se detallan a continuación como interacciones de servicios. Un aspecto clave de un grafo dirigido es determinar si es cíclico o no. El caso de los grafos dirigidos sin bucles, es decir, no cíclicos es más simple. En algunas aplicaciones, se necesita una aproximación iterativa; por lo tanto la cadena debe ser cíclica con condiciones en la función de control para tratar la convergencia. Las cadenas pueden considerarse como plantillas o como grafos inmutables. Una plantilla es un grafo dirigido que define la cadena basada en clases abstractas, incluyendo la Noviembre de

22 identificación de cada tipo de servicios. Una plantilla puede ser requerida como un grafo inmutable, en el momento en que se fijan las instancias de servicio. Caracterizan una cadena de servicios, los siguientes elementos adicionales: cadenas en paralelo versus serie: Tiene el grafo dirigido caminos paralelos basados en bifurcaciones o sólo se permiten cadenas secuenciales? Los potenciales tipos de bifurcaciones incluyen: Si/sino, unión, selección y disparador; iteración Opera un nodo del grafo dirigido como una iteración, por ejemplo, con bucles con contador y bucles con condición?; tipo de transporte de datos: Se permiten variaciones en el grafo dirigido en los enlaces entre nodos de modo que reflejen diferentes métodos de transporte de datos o de invocación de servicios?; parámetros de los nodos: Contiene la descripción de los nodos del grafo dirigido parámetros que puedan cambiarse?; variaciones en el patrón del diseño de control: procesamiento de presión y procesamiento de atracción Modelo UML de una cadena La Figura 4 provee un modelo UML de una cadena. Figura 4. Cadena De acuerdo con la Norma ISO/TS 19103, el modelado de grafos dirigidos para cadenas de servicios debe realizarse usando el diagrama de actividades del Lenguaje de Noviembre de

23 Modelado Unificado (UML Unified Modeling Language). Un diagrama de actividades representa los estados de ejecución de una cadena de servicios. La Tabla 3 muestra los elementos de un diagrama de actividad. Tabla 3. Entidades de un diagrama de actividades UML Elementos de un diagrama de actividades Estado de actividad Transición Bifurcación / Unión Despliegue / Unión Señal Descripción del encadenamiento de servicios Un estado que representa la ejecución de un servicio, normalmente proyectado por la petición de una operación. Una relación entre dos estados. Una transición indica que se ejecuta la acción especificada en el primer estado y se presenta en el segundo estado cuando un evento ocurre y se satisfacen algunas condiciones. El comienzo/fin de hilos de ejecución alternativos en un diagrama de actividades. El comienzo/fin de hilos de ejecución concurrentes en un diagrama de actividades. Una comunicación asíncrona entre servicios planificados para disparar transiciones en un diagrama de actividades Carpeta para organizar servicios Los servicios son de muchos tipos, tal como se indica en el apartado 8.3, pero sólo un conjunto de los servicios disponibles se aplica en una situación determinada, por ejemplo el análisis de imágenes. Una carpeta para organizar servicios (SOF Service Organizer Folder) es una ayuda para los usuarios a la hora de buscar los servicios aplicables en su situación. Un usuario puede implementar un SOF y hacer a ese SOF disponible a otros usuarios que realizan tareas en situaciones similares. Una carpeta para organizar servicios es una estructura de datos que debe contener referencias a un conjunto de servicios aplicables en una situación determinada. El SOF no debe contener cadenas de servicios, sino que únicamente puede contener servicios individuales Servicios que permiten el encadenamiento de servicios La Tabla 4 presenta una lista de servicios que se requieren que estén disponibles para el encadenamiento de servicios. Noviembre de

24 Estos servicios están localizados en el marco de trabajo OSE extendido. Los detalles de los servicios pueden ser encontrados en el apartado 8. Algunos de los servicios son comunes a todo el dominio IT. Otros servicios son específicos a los datos geográficos y a conjuntos de datos geográficos de gran tamaño. Tabla 4. Servicios que permiten el encadenamiento de servicios Servicios necesarios para permitir el encadenamiento de servicios Categorías OSE Servicios generales IT Servicios geográficos Servicios de interacción humana Servicios de tareas/flujos de trabajo Servicios de procesamiento Servicios de gestión de modelos/ información Servicios de gestión de sistemas Servicios de comunicaciones _ Servicio central de servicios para la definición, control y monitorización de cadenas de servicio Servicio central de catálogo que visualiza y navega por metadatos sobre servicios Servicio de promulgación de flujos de trabajo para definir, invocar, monitorizar y controlar encadenamientos de servicios (opcionalmente, iteracción con otros flujos de trabajo) Servicio de validación de cadenas de servicio Reserva de recursos y mecanismos de coasignación tanto para sistemas de almacenamiento como otros recursos tales como redes, con el fin de suministrar las garantías punto a punto requeridas para transferencias previsibles Catálogo de metadatos de instancias de servicio, con localización y gestión de subservicios Registro de tipos de servicios, con localización y gestión de subservicios Intermediación Mediación Autorización y autentificación; Métodos de apago Privacidad del cliente Medición del rendimiento y técnicas de estimación de los recursos clave involucrados en la operación de la trama de datos, incluyendo los sistemas de almacenaje, redes y ordenadores; Servicios de instrumentación que permitan la instrumentación fin a fin de la transferencia de almacenamiento y otra operación Mecanismos de mensajería Transferencia de grandes objetos de datos Gestión de ejecutables y ficheros remotos: proporciona acceso a almacenamiento secundario como si fuera local Conversión de formatos Servicio central de catálogo que localiza, navega y gestiona metadatos sobre datos espaciales Servicio central espacial para la edición, representación, consulta y análisis de datos de los mapas Servicio central de cálculo que permite la visualización y manipulación de datos geográficos usando un formato de hoja de cálculo Servicios de procesamiento geográfico (véase el apartado 8) Instancia de conjunto de datos geográficos Catálogo de metadatos geográficos con subservicios de gestión, acceso y localización Conversión de formatos geográficos Noviembre de

25 Patrones de arquitectura para encadenamiento de servicios Introducción Este apartado provee patrones de arquitectura para encadenamiento de servicios. Los patrones de arquitectura usan las plantillas presentadas en el apartado 6.6. Hay muchas opciones para la asignación de servicios de encadenamiento de servicios a componentes. Diferentes enfoques de asignación reflejan diferentes prioridades para diferentes aplicaciones: usuarios en el bucle o usuarios supervisores. Para demostrar la amplitud del margen de cambio de esta variación, se ofrecen tres patrones de diseño que varían la asignación de la función de control: encadenamiento definido por el usuario (transparente): la persona gestiona el flujo de trabajo; encadenamiento de flujo de trabajo gestionado (translúcido): en el que la persona invoca un servicio de gestión de flujo de trabajo que controla la cadena y el usuario es consciente de la existencia de servicios individuales; servicios agregados (opaco): en el que el usuario demanda un servicio que lleva a cabo una cadena, de ese modo el usuario no es consciente de la existencia de servicios individuales. Además de la diferencia de visibilidad que el usuario tiene de los servicios, una distinción clave entre estos patrones es la diferenciación del control. En el encadenamiento transparente, el control es exclusivamente del usuario. En el translúcido, está presente un servicio de flujo de trabajo que controla la ejecución de la cadena, posiblemente con supervisión de la persona. En el patrón agregado, el servicio de agregación realiza la función de control de forma exclusiva y sin visibilidad por parte del usuario Encadenamiento definido por el usuario (transparente) Nombre Implica que el usuario define y controla el orden de ejecución de los servicios individuales. Los detalles de los servicios no son ocultados al usuario, de esa manera, el alias de este patrón es encadenamiento transparente Problema En este patrón, el usuario conoce como pueden combinarse los servicios. El usuario localiza y evalúa los servicios disponibles, determina si son adecuados a sus necesidades, determina una secuencia válida de servicios y controla el encadenamiento. Noviembre de

26 Este patrón presupone que el usuario tiene conocimientos previos. Se le proporciona al usuario información suficiente para realizar decisiones de control Contexto El usuario remite una petición a un servicio de catálogo para localizar servicios de su interés. No existe una cadena específica anterior a la que el usuario inicia. El usuario tiene la capacidad de definir una cadena válida y/o es capaz de modificar la cadena implicada en el caso de que se produzcan fallos en la ejecución Obligaciones El usuario debe tener la capacidad de diseñar una cadena que sea eficiente para después ejecutarla. Las entradas y salidas de los servicios individuales tienen que ser compatibles, o tiene que añadirse un servicio de intervención, por ejemplo, translación de formatos. Estos patrones asumen que cada servicio tiene los suficientes recursos para ejecutarse eficientemente, pero el usuario puede necesitar seleccionar los servicios basándose en consideraciones de red, por ejemplo, el ancho de banda de la red, la seguridad, la autenticación. La corrección semántica de la cadena la realiza el usuario; asuntos tales como cuando los datos son remuestreados en una cadena afectarán a la validez de los resultados. Un usuario puede iterar una cadena hasta que logre un resultado aceptable, resultando una cadena que puede ser guardada y utilizada por otros, quizás usando un patrón de encadenamiento de flujo de trabajo Estructura el usuario. En la Figura 5 se muestra el patrón de arquitectura de encadenamiento definido por Nota: La única característica del patrón transparente es que el usuario define y controla la cadena. En la figura, el usuario localiza un servicio disponible a través de un servicio de catálogo. Las alternativas del usuario para seleccionar los servicios forman parte de este patrón. Por ejemplo, el catálogo podría sustituir a una carpeta para organizar servicios. Noviembre de

27 Figura 5. Encadenamiento transparente. Patrón de arquitectura de encadenamiento definido por el usuario Tabla 5. Descripción de los pasos en la figura 5 Paso 1. Petición de búsqueda Paso 2. Resultado de búsqueda Paso 3. Solicitud del servicio Paso 4a. Solicitud del servicio Paso 4b. Petición de entrada Paso 5a. Solicitud del servicio Paso 5b. Petición de entrada Paso 5c. Petición de entrada Una persona usa un cliente para enviar una petición de búsqueda (o serie de búsquedas) a un servicio de catálogo. El servicio de catálogo proporciona consultas sobre los metadatos de servicio El servicio de catálogo devuelve los metadatos sobre los servicios interesantes para el usuario. Para este ejemplo, el usuario ha encontrado tres servicios que se encadenarán. El usuario solicita un servicio usando un cliente, que causa un resultado que está disponible para el siguiente servicio. El usuario solicita un segundo servicio usando el cliente. La petición incluye una referencia al resultado del paso anterior. El servicio crea un resultado que está disponible para el próximo servicio. El usuario solicita un tercer servicio usando el cliente. La petición incluye referencias a los resultados de los servicios previos. Este tercer servicio devuelve un resultado al cliente. Noviembre de