• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Sistemas de información distribuidos
 

Sistemas de información distribuidos

on

  • 4,159 views

aqui unas diapos de si distribuidos

aqui unas diapos de si distribuidos

Statistics

Views

Total Views
4,159
Views on SlideShare
4,159
Embed Views
0

Actions

Likes
1
Downloads
103
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Sistemas de información distribuidos Sistemas de información distribuidos Presentation Transcript

    • Sistemas de Información Distribuidos Ing. Aldo Zanabria Gálvez UNAP Puno. 2010 9no Semestre – Ingeniería de Sistemas 17/03/11 UNAP - Ing. Aldo Zanabria
    • 17/03/11 UNAP - Ing. Aldo Zanabria Arquitectura Cliente/Servidor
    • Justificación Cliente/Servidor 17/03/11 UNAP - Ing. Aldo Zanabria
    • Nuevas Tareas del Dpto. de Sistemas de Información
      • Soporte a la gestión empresarial. Apoyo a los objetivos.
      • Selección de Estándares:
        • Compatibiliza.
        • Facilita al usuario.
      • Infraestructura C/S:
        • Plataforma operativa.
        • Entorno de desarrollo.
        • Gestión del SID.
        • Arquitectura de la aplicación:
          • Portabilidad.
          • Interoperatividad.
          • Distribuida.
      • Desarrollo corporativo (no departamental).
      • Integración de aplicaciones propias con estándar.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Implicaciones del modelo Cliente/Servidor 17/03/11 UNAP - Ing. Aldo Zanabria
    • ¿Cuándo implantar C/S?
      • Cambios estructurales y organizativos.
      • Cambios en organigramas.
      • Respuesta dinámica de mercado.
      • Cambio en procesos de negocio.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • ¿Qué ayuda a la implantación?
      • La demanda de sistemas fáciles.
      • Precio/rendimiento de estaciones y servidores.
      • Creciente acceso a la información para decisiones: Separación datos-programas. Programas flexibles.
      • Nuevas tecnologías de alta productividad.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Cliente/Servidor
      • Definición : Sistema distribuido entre múltiples procesadores donde hay clientes que solicitan servicios y servidores que los proporcionan.
      • Separa los servicios situando cada uno en su plataforma más adecuada.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Objetivos de C/S
      • Localización transparente.
      • Recursos compartidos.
      • Escalabilidad
        • Horizontal: > nº estaciones.
        • Vertical: migración a otras plataformas.
      • Interoperatividad entre distintos Hw. y Sw.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Evolución
      • 1ª ÉPOCA:
        • LAN.
        • LAN con MAINFRAMES.
        • Comunicaciones homogéneas (LU, SNA, APPC).
      • 2ª ÉPOCA:
        • Herramientas de desarrollo C/S.
        • Proveedores DBMS con C/S.
        • Downsizing: migración a PCs.
        • S.O. De red con servidores de servicios.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Evolución (II)
      • 3ª ÉPOCA: ACTUAL.
        • PWS: Estaciones de trabajo programables gráficamente.
        • GUI: Interfaz gráfico de usuario. Alta resolución.
        • Nuevas tecnologías: Ratón, lápiz óptico, scanner, multimedia.
        • Tecnología de componentes: DDE y OLE.
        • Conectividad de BDs: ODBC, JDBC
        • Objetos Distribuidos: CORBA, COM, COM+, DCOM
        • Internet: HTML, CGI, Applet, ActiveX, JAVA, JAVASCRIPT
        • Arquitecturas C/S de 2 y 3 niveles.
        • Middleware.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Tecnología de componentes: DDE y OLE
      • DDE : (Dynamic Data Exchange) ( Microsoft ).
        • Enlaces de datos dinámicos.
        • Información automáticamente actualizada entre aplicaciones.
      • OLE : (Object Linking and Embeding) ( Microsoft ).
        • Objetos enlazados y embebidos.
        • Enlazado: Guardando una referencia.
        • Embebido: Insertando un documento.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Conectividad de BDs
      • ODBC : (Open DataBase Conectivity) ( Microsoft ).
        • Conectividad abierta entre BDs.
        • Interfaz de conexión entre BDs (especialmente Microsoft)
      • JDBC : (Java DataBase Conectivity) ( Java ).
        • Conectividad abierta entre BDs versión Java.
        • Abierto.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Objetos Distribuidos
      • CORBA ( Common Object Request Broker Architecture) ( Object Management Group ): Estándar de programación distribuida basada en objetos.
      • COM ( Microsoft ): Interface estándar para objetos (no importa cómo están programados).
      • COM+ ( Microsoft ): Extensión de COM en el que se añade un modelo para la programación de objetos.
      • DCOM ( Microsoft ): Extensión de COM que permiten crear objetos clientes y servidores utilizando COM aunque creando transparencia sobre la localización física del objeto (es decir que puede encontrarse en otra máquina). La gestión de la comunicación está embebida.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • INTERNET
      • HTML (HyperText Markup Language ) : Lenguaje basado en el estándar SGML de etiquetado para la creación de páginas web en el servidor visibles desde un cliente remoto con su propio visor.
      • CGI (Common Gateway Interface): Interface para el tratamiento de ejecutables en el servidor (remoto) a petición de clientes. Rápido y muy modular.
      • ActiveX ( Microsoft ) : Objetos visuales de control (desde botones hasta mini-aplicaciones) embebidos en un documento (o página web) que se descargan y se ejecutan en el visor del cliente.
      • JAVA ( Sun Microsystems ) : Lenguaje de programación específico para C/S en internet. Lento, con aplicaciones mayores.
      • APPLET : Objetos visuales embebidos en una página web (versión abierta de ActiveX).
      • JAVABEANS ( Sun Microsystems ) : Especificación para objetos en Java.
      • JAVASCRIPT ( Netscape ) : Lenguaje de utilidades para HTML.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Evolución (III)
      • EL FUTURO.
        • Facilidad de uso de las aplicaciones.
        • Accesos a datos distribuidos en cualquier lugar del mundo (y del espacio).
      17/03/11 UNAP - Ing. Aldo Zanabria
    • MIDDLEWARE
      • Conecta procesos para constituir aplicación.
      • Conjunto de funciones + servicios.
      • Actúa en el bajo nivel del SID:
        • Comunicación.
        • Directorios.
        • Integridad.
      • Define la plataforma de transparencia de localización.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Características C/S.
      • Flexibilidad:
        • Middleware.
        • Separación de funciones:
          • Lógica de presentación.
          • Lógica de negocio.
          • Lógica de datos.
        • Encapsulación de servicios.
        • Portabilidad - reubicación.
        • Operación sincrono - asíncrono.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Características C/S (II).
      • Entorno de aplicaciones incremental.
        • Añadir un nuevo servidor.
        • Añadir un nuevo cliente.
        • Modificar un cliente para usar un nuevo servidor.
      • Integración: por la GUI.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Modelos C/S
      • Presentación distribuida
        • Proporciona un API que separa la programación de ventanas del resto.
        • Ejemplo: X-Windows System en UNIX o Windows95 y NT.
      17/03/11 UNAP - Ing. Aldo Zanabria Presentación Negocio Datos C S
    • Modelos C/S (II)
      • Función distribuida
        • Máxima flexibilidad.
        • Lógicas de negocio separadas.
      17/03/11 UNAP - Ing. Aldo Zanabria Presentación Negocio Datos Negocio C S
    • Modelos C/S (III)
      • Datos distribuidos
        • Ficheros distribuidos.
        • Bases de datos distribuidas.
      17/03/11 UNAP - Ing. Aldo Zanabria Presentación Negocio Datos C S
    • Aplicaciones de 2 y 3 niveles
      • 2 niveles:
        • Generalmente usa los modelos de función distribuida o datos distribuidos.
        • Muy productivo.
        • Distribución no flexible.
        • Dependiente del suministrador.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Aplicaciones de 2 y 3 niveles (II)
      • 3 niveles:
        • Modelo presentación-negocio-datos
        • Distribución flexible.
        • Sistema abierto. No dependiente.
      17/03/11 UNAP - Ing. Aldo Zanabria C C C Negocio
    • Sistemas abiertos
      • Definición según IEEE:
      • “ Un conjunto completo y consistente de estándares internacionales de tecnología de información y de estándares funcionales, que especifica interfaces, servicios y formatos de soporte para conseguir la interoperatividad y portabilidad de aplicaciones, datos y personas”.
      • Definición según ISO:
      • “ Todo el conjunto de interfaces, servicios y formatos de soporte, además de otros aspectos de usuarios, para la interoperativilidad o la portabilidad de aplicaciones, datos o personas, según se especifica en los estándares y perfiles de tecnología informática”
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Sistemas Abiertos: Características.
      • Elección libre de plataforma gracias a la portabilidad e interoperatividad.
      • Protección de la inversión empresarial.
      • Libertad de elección del modelo de distribución: presentación, función o datos distribuidos.
      • Explotación de aplicaciones estándar.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Estándares
      • Definición: “Conjunto de reglas, definiciones y propiedades mutuamente aceptadas que permite la cooperación de objetos heterogéneos y su utilización”
      • Clasificación:
        • Por su lugar de publicación:
          • Internacional
          • Regional (CEE).
          • Nacional.
        • Por autor:
          • De Iure: por comité
          • De facto: por fabricante.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Sistemas abiertos vs propietarios
      • Tiempo de implantación mayor en abiertos:
        • Estándar  10 años.
        • Alianzas y consorcios (no oficial): medio plazo.
        • Tecnologías propietarias portables: corto plazo.
        • Tecnologías propietarias: Rápidas. No abiertas.
      • Diferenciador de producto:
        • Estándar industrial + algo propio.
        • Ejemplo: un DBMS con SQL estándar + 4GL propio.
      • Arquitecturas de proveedores importantes.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Sistemas Abiertos: Factores de éxito.
      • Independencia del suministrador.
      • Elección de herramientas:
        • Interoperativas: Estándares.
        • Portables: Estándar o propietario.
      • Arquitectura de la aplicación:
        • Buen diseño C/S.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Plataformas operativas: Gestores de recursos
      • Definición: ”Programas software que acceden a recursos (dispositivos, ficheros, bases de datos, programas, objetos, etc.) y proporcionan un API”.
      • Tipos:
        • Local: servicio en s.o. local.
        • Remoto: con C/S.
        • Distribuido: en varios lugares.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Plataformas operativas: Middleware
      • Función de intermediario entre clientes y servidores.
      • Otros servicios:
        • Directorio de recursos: info. sobre ellos.
        • Nominación de recursos.
        • Comunicaciones:
          • Conversacional (SINC)
          • RPC: (SINC)
          • Cola de mensajes: (ASINC)
        • Seguridad: Login único.
        • Gestión de transacciones: única para todos los recursos.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Selección de sw C/S
      • Sistema operativo.
      • Múltiples modelos de distribución C/S.
      • Nuevas tecnologías (POO).
      • Apertura.
      • Integración con sw estándar.
      • Operación C/S (síncrona y asíncrona).
      • Herramientas de desarrollo potentes.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Ejercicios: 17/03/11 UNAP - Ing. Aldo Zanabria
    • Ejercicio 1
      • 1) Una empresa localizada en una determinada ciudad A dispone de un sistema con un ordenador multiprocesador de 2 CPUs, con 16 Mbytes de RAM, 2 discos de 1 Gb yte cada uno, 2 terminales locales y una impresora láser en un edificio. Además esta empresa dispone de una delegación situada en una ciudad B a 300 km. de la anterior donde se conecta vía módem un terminal a 9600 bps con una impresora local a éste. En el ordenador central se ejecutan 3 procesos distintos: uno para gestión de los datos de la empresa central, otro para gestionar los de la delegación y un tercer proceso traspasa información entre la base de datos de la central y la de la delegación. Discutir razonadamente:
      • a) ¿Podríamos estar ante un sistema distribuido?
      • b) ¿Es razonable esta forma de trabajar? ¿Por qué?
      • c) ¿Es mejorable? ¿Cómo?
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Ejercicio 2
      • 2) Supongamos la misma empresa del ejercicio 1 donde ahora tenemos un ordenador en la central y otro ordenador en l a delegación conectados entre sí por un módem de 14400 bps. Cada lugar tiene su propia base de datos y sus propios procesos, y un proceso situado en la central se encarga del traspaso de datos entre las dos empresas. Este proceso lo pone en marcha un opera dor cuando necesita mover los datos de sitio. ¿Es este sistema distribuido? ¿Por qué?
      17/03/11 UNAP - Ing. Aldo Zanabria
    • CONSIDERACIONES: Aspectos a considerar, tendencias, Desarrollo web, nuevos tipos de dispositivos. 17/03/11 UNAP - Ing. Aldo Zanabria
    • Aspectos a tener en cuenta en el proceso de ingeniería
      • Protocolos de comunicaciones:
        • Son más importantes que la propia arquitectura distribuida o centralizada. Un buen protocolo permite que se pueda pasar, sin un coste adicional de rediseño o codificación, de una arquitectura centralizada a una distribuida, y viceversa:
          • Pipes
          • RPC
          • SQL Remoto
          • HTTP
          • X11
          • Otros
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Aspectos a tener en cuenta
      • Middleware. Es la herramienta o conjunto de herramientas que nos permitiran gestionar y coordinar los mecanismos de comunicación.
        • Independiza el servicio y su implementación, del S.O. y protocolos de comunicaciones
        • Permite la convivencia de distintos servicios en una misma máquina
        • Modelo tradicional: Monitor de teleproceso
          • CICS, Tuxedo, Encina
        • Modelo OO: CORBA
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Aspectos a tener en cuenta
      • Fase de análisis:
        • Prácticamente no hay diferencias respecto a un S.I. tradicional
        • Se debe definir la política de empresa: fat client o fat server.
        • Se debe definir el coste en comunicaciones que puede asumir la organización.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Aspectos a tener en cuenta
      • Fase de diseño
        • El diseño de entidades, en raras ocasiones se verán éstas afectadas
        • Aparecerán nuevos conjuntos de datos en los DFDs. No se trata de nuevas entidades, sino de información que debe viajar entre nodos
        • Respecto al diseño de tablas, se debe especificar su implementación:
          • Desde qué nodos debe ser accesible
          • Qué nivel de acceso se precisa desde cada uno de ellos
          • Cómo implementarlo
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Aspectos a tener en cuenta
      • Implementación BB.DD. Distribuidas
        • No hay entornos puramente distribuidos. Debe analizarse, tabla a tabla, qué distribuir, qué centralizar y cómo hacerlo:
        • Tabla única
        • Tablas con réplica simétrica on-line
        • Tablas con réplica simétrica off-line **
        • Tabla maestra más copias instantáneas
        • Tabla maestra más copias instantáneas actualizables **
        • Especial atención a las secuencias !!
        • Especial atencíón a los conflictos de réplica (**)
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Aspectos a tener en cuenta
      • Diseño de procesos
        • Se deberán tener en cuenta, no tan sólo los procesos de réplica y su periodicidad, sino el ancho de banda que consuman, máxime si implican tarificación por paquetes trasnmitidos:
          • Pipes y sockets -> Aproximación analítica
          • Middleware -> Información a transmitir + Sobrecoste en ancho de banda + Sobrecoste en tiempo de proceso
          • Protocolos propietarios (SQL) -> Recurrir a benchmarks o referencias del fabricante
        • Analizados los consumos de ancho de banda y tiempo estimado de proceso, se deberá replantear la idoneidad de ubicación de cada proceso
        • Extremar las pruebas cuando se requiera diseñar e implementar protocolos de comunicación
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Aspectos a tener en cuenta
      • Fase de pruebas. Debido a la complejidad del sistema, serán necesarias varias fases:
        • Pruebas de funcionalidad de la aplicación. Se puede llevar a cabo sobre máquinas de desarrollo y estaciones de trabajo de forma paralela
        • Pruebas de carga del servidor
        • Pruebas de integridad de datos. Son especialmente importantes en el caso de bases de datos distribuidas
        • Pruebas transaccionales
        • Pruebas de red
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Desarrollos Web
      • Caso particular de desarrollo cliente servidor con representación remota, en la cual disponemos de un protocolo standard: HTTP y un middleware denominado WebServer.
      • Cada página puede desencadenar la solicitud de numerosos peticiones adicionales para finalizar el proceso de representación remota.
      • Se dispone de un lenguaje standard de definición y formateo de páginas: HTML
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Desarrollos Web
      • Incrustación de la lógica de aplicación en el servidor Web:
        • CGI: Common Gateware Interface
          • Cada petición HTTP genera un nuevo proceso, el cual analiza la solicitud y genera un resultado. Cada proceso corresponde a una transacción.
          • Es flexible, ideal para pequeñas aplicaciones de uso reducido
          • No escala adecuadamente
        • Páginas ASP: Caso particular de CGI
          • Entorno propietario Microsoft
          • Aspectos de rendimiento bastante mejorados
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Desarrollos Web
      • Incrustación de la lógica de aplicación en el servidor Web
        • Servlets: Ejecución de aplicaciones Java en el servidor que procesan la petición y generan la página de respuesta
          • No generan un proceso adicional por cada petición
          • Utilizan un lenguaje de alto nivel (Java)
        • Objetos CORBA:
          • Pemite la integración de objetos CORBA con el servidor Web, creando una estructura cliente servidor multinivel
          • Es la solución más generalista y adaptable
          • Permite fácil, flexible y eficiente integración con BBDD
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Desarrollos Web
      • Esquema general
      17/03/11 UNAP - Ing. Aldo Zanabria Navegador Web Server Servlet Máquina virtual Java Conector CORBA Servidor CORBA Procesos CGI HTTP Parámetros proceso CORBA RMI Base de datos
    • Nuevos tipos de dispositivos
      • Dispositivos que acceden hoy a internet:
        • Internet Explorer, Netscape, Set Top Box, Móviles WAP, PDAs Palm Pilot, Windows CE, ...
      • Previsiones para los próximos años:
        • 2.002 el 50% de las transacciones habituales se podrán realizar desde dispositivos móviles
        • 2.003 el 80% de los usuarios realizarán algún tipo de transacción desde dispositivos móviles
        • 2.004 los se querrán realizar el 100% de las transacciones desde dispositivos móviles
        • 2.005 Se esperan más de 1.000 millones de usuarios móviles de internet
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Nuevos tipos de dispositivos
      • Problema a resolver:
        • Necesidad de adaptar el interface de usuario a cada tipo de dispositivo
      • Medidas a tomar:
        • Separar la lógica de aplicación del interface de usuario
        • Utilizar métodos estándar de comunicación entre la lógica de aplicación y el interface de usuario
        • Uso de herramientas que permitan adaptar rápidamente las aplicaciones a los nuevos tipos de dispositivos que irán apareciendo
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Nuevos tipos de dispositivos
      • Tendencia actual
      17/03/11 UNAP - Ing. Aldo Zanabria Navegador Web Server Páginas HTML Servidor Aplicaciones Lógica de negocio Datos Interface de usuario Gestor comunicaciones Usuario Móvil WAP Server Páginas WML SQL XML - - Wml binario http Base de datos
    • Nuevos tipos de dispositivos
      • Variante de los fabricantes BBDD
      17/03/11 UNAP - Ing. Aldo Zanabria Navegador Web Server Páginas HTML Lógica de negocio Datos Interface de usuario Gestor comunicaciones Usuario Móvil WAP Server Páginas WML XML - - Wml binario http Base de datos
    • Nuevos tipos de dispositivos
      • Variante de los fabricantes pasarelas
      17/03/11 UNAP - Ing. Aldo Zanabria Navegador Web Server Páginas HTML Lógica de negocio Datos Interface de usuario Gestor comunicaciones Usuario Móvil WAP Server Reglas de traducción WML SQL - - Wml binario http Interface de usuario Base de datos
    • Estrategia a seguir
      • Valorar la durabilidad temporal de las tecnologías a aplicar
      • Separar, en el diseño e implentación de la aplicación, las capas de lógica de aplicación e interface de usuario
      • Prestar mucha atención a los nuevos tipos de dispositivos
      • Examinar con lupa los “atajos” ofrecidos por los fabricantes
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Costes sistema distribuido
      • Elementos a valorar:
        • Coste de las comunicaciones: Valorar alternativas presentadas por los nuevos proveedores de telecomunicaciones. No descartar el tirar líneas propias
        • Evaluar el coste adicional en hardware, software y gestión que implica una arquitectura distribuida. Si las comunicaciones lo permiten, saldrá más rentable una arquitectura centralizada
        • El impacto de los protocolos de comunicaciones será vital en el desglose posterior de costes. Se deben dedicar todos los esfuerzos necesarios para evaluar cuál es el protocolo óptimo.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • 17/03/11 UNAP - Ing. Aldo Zanabria Tecnología de objetos distribuidos y arquitectura de componentes.
    • 17/03/11 UNAP - Ing. Aldo Zanabria Índice 1. Introducción. 2. OMA (Object Management Architecture) . 3. CORBA (Common Object Request Broker Architecture) . 4. Conclusiones.
    • Introducción 17/03/11 UNAP - Ing. Aldo Zanabria Datos C/S 2 capas Evolución de la arquitectura de los sistemas informáticos Sistemas monolíticos C/S 3 capas BD Negocio Presentación Negocio Presentación Datos Negocio Datos Negocio Presentación
    • 17/03/11 UNAP - Ing. Aldo Zanabria BD Arquitectura multicapa Presentación Negocio Datos subcapas
    • 17/03/11 UNAP - Ing. Aldo Zanabria Arquitectura de componentes (I) (multicapa y 3-tier) 3:Component system 2:Component frameworks 1:Components
      • Tier 1: Arquitectura de componentes individuales.
      • Tier 2: Arquitectura de los marcos de componentes. Macro-componentes definidos para realizar una función de negocio concreta.
      • Tier 3: Arquitectura del sistema de componentes. Super-componente que define todo el sistema.
      ( tier  grada )
    • 17/03/11 UNAP - Ing. Aldo Zanabria Arquitectura de componentes (II)
      • Cada componente del tier 3 se define con un conjunto de componentes del tier 2, y cada uno del tier 2 por un conjunto del tier 1.
      • COMPONENTE = módulo + conjunto de recursos
        • Módulo = conjunto de clases y puede que elementos de proceso no orientados a objeto (procedimientos y funciones).
        • Conjunto de recursos = múltiples interfaces que cada uno representa un servicio ofrecido por el componente.
      • COMPONENTE  OBJETO
    • 17/03/11 UNAP - Ing. Aldo Zanabria
      • Problemas:
        • No basta una modelización correcta de jerarquía de clases e interacciones, se necesita una infraestructura (nivel de transporte) de comunicación que permita el flujo transparente de mensajes entre objetos de distintas aplicaciones en distintas máquinas
        • Se debe evitar el crecimiento exponencial de interfaces
      • Solución:
        • Middleware de componentes
      Arquitectura de componentes (III)
      • Alternativas:
        • Sockets.
          • Implementación costosa.
        • Remote Procedure Calls ( RPC ).
          • No soporta objetos explícitamente.
        • Microsoft Distributed Component Object Model ( DCOM )
          • Menos maduro, menos portable y además propietario.
        • Java Remote Method Invocation ( RMI )
          • Solo para JAVA.
        • Common Object Request Broker Architecture ( CORBA )
          • Multiplataforma, multilenguaje, ...
      17/03/11 UNAP - Ing. Aldo Zanabria Arquitectura de componentes (IV)
    • OMA (Object Management Architecture)
      • OMG: Object Management Group, Inc.
      • http://www.omg.org
        • Fundado en 1989.
        • Objetivo: Desarrollo de estándares para la reutilización , portabilidad e interoperabilidad de software orientado a objetos en entornos heterogéneos y distribuidos.
        • Solución: Definen OMA (Object Management Architecture) de la cual CORBA es una parte.
        • Historia:
          • 1991: CORBA 1.1
          • 1995: CORBA 2.0 (Modelo de Referencia)
          • 2000: CORBA 2.4 (actual)
          • 2000-2001: CORBA 3.0 (Modelo de Componentes) (en desarrollo)
      17/03/11 UNAP - Ing. Aldo Zanabria
    • OMA: Objetivos técnicos
      • Transparencia distribución
      • Rendimiento local y remoto
      • Comportamiento dinámico
      • Sistema de nombrado
      • Consultas: nombre, atributos, relaciones
      • Control de la concurrencia
      • Transacciones
      • Robustez, disponibilidad
      17/03/11 UNAP - Ing. Aldo Zanabria
      • Mantenimiento de versiones
      • Notificación de eventos
      • Semántica de Relaciones entre objetos
      • API en C para todas las operaciones
      • Administración y gestión
      • Internacionalización
      • Estandarización
    • Arquitectura del modelo de referencia OMA 17/03/11 UNAP - Ing. Aldo Zanabria Application objects CORBA facilities Object services (CORBAservices) CORBA 2.0 Object Request Broker (ORB)
    • Object services (CORBAservices) (I)
      • Definen 16 servicios comunes ofrecidos a los objetos:
        • Naming service : Identificación de objetos
        • Object security service : Servicio de seguridad
        • Object trader service : Mercader de objetos. Los ofrece a los clientes.
        • Object transaction service : Permite transacciones con commit-rollback
        • Change management service : Gestor de versiones de implementación.
        • Concurrency service : Gestión de bloqueos para permitir concurrencia
        • Event notification service : Objetos que son mensajes de eventos
        • Externalization service : Permite copiar objetos por valor
        • Licensing service : Permite obtener licencias de uso de un objeto
        • Lifecycle service : Crea, copia, mueve y borra objetos y grupos de objetos relacionados
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Object services (CORBAservices) (II)
        • Object collections service : Crea colecciones de objetos (basado en SMALLTALK) (árboles, listas, colas, conjuntos,...)
        • Object query service : Permite localizar los objetos por el valor de sus atributos (parecido al Trader, pero en lugar de servicios ofrece atributos)
        • Persistent object service : Permite al objeto sobrevivir a la terminación del programa que lo creó
        • Properties service : Asocia propiedades al objeto (modificable, borrable o sólo lectura)
        • Relationship service : Permite relaciones entre objetos
        • Time service : Soluciona el problema del reloj asíncrono en los SID. Usa time-stamping .
      17/03/11 UNAP - Ing. Aldo Zanabria
    • CORBAfacilities
      • Definen servicios comunes ofrecidos a las aplicaciones:
        • Horizontales: define colecciones de objetos prefabricados
          • Interfaz de usuario
          • Gestión de la información
          • Gestión de sistemas
          • Gestión de tareas
        • Verticales: define servicios comunes para un dominio completo (framework tier)
          • Objetos de negocio
          • Comercio electrónico
          • Finanzas
          • Manufacturación
          • Medicina
          • Telecomunicaciones
      17/03/11 UNAP - Ing. Aldo Zanabria
    • Application objects
      • Definen servicios específicos de un determinado negocio o aplicación.
      • Suponen el nivel más alto de los servicios soportados por la arquitectura OMA
      17/03/11 UNAP - Ing. Aldo Zanabria
    • CORBA (Common Object Request Broker Architecture) 17/03/11 UNAP - Ing. Aldo Zanabria
      • CORBA es un middleware orientado a objetos / componentes.
      • Los objetos cliente solicitan servicios a los objetos servidor mediante invocación de método
      • Separa interfaz e implementación
      • Es independiente del lenguaje: los objetos clientes y servidores se implementan en cualquier lenguaje (de los soportados)
      • Crea transparencia de localización a través del ORB :
        • de objetos: la invocación siempre se hace en local
        • de red: el ORB la gestiona
        • de activación: los servidores se activan automáticamente
        • de estado persistente: permite que el servidor guarde persistencia y es transparente al cliente
    • IDL (Interface Definition Language)
      • CORBA incorpora un lenguaje de definición de interfaces (IDL)
      • Independiente del lenguaje de implementación.
      • Mapea hacia los lenguajes de programación habituales.
      • Los ORBs llevan incorporados su traductor de IDL a los lenguajes de implementación soportados
      17/03/11 UNAP - Ing. Aldo Zanabria C C++ Ada Java IDL SmallTalk Object Request Broker (ORB) Delphi
    • 17/03/11 UNAP - Ing. Aldo Zanabria Comunicación C/S en CORBA Cliente Servidor Object Request Broker (ORB) Invocation Interface Object Adapter
    • 17/03/11 UNAP - Ing. Aldo Zanabria Object Request Broker (ORB) Arquitectura de CORBA Dynamic Invocation Interface IDL Stubs ORB Interface IDL Static Skeletons Dynamic Skeleton Interface Object Adapter Interface Repository IDL COMPILER Implementation Repository Client Object (Servant) OBJ REF operación(args) resultado(args)
    • 17/03/11 UNAP - Ing. Aldo Zanabria Componentes primarios en CORBA (I)
      • Object :
        • Entidad de programación CORBA.
        • Tiene una identidad, una interfaz, y una implementación (conocida como Servant).
      • Servant (sirviente) :
        • Implementación de una entidad en un lenguaje de programación (en cualquiera de los soportados).
        • Define las operaciones que soporta un determinado interfaz CORBA IDL.
      • Client :
        • Entidad de programa que invoca una operación a una implementación de objeto.
        • Idealmente será tan simple como una invocación a un método.
      • Object Request Broker (ORB) (corredor de peticiones a objetos) :
        • Núcleo de la arquitectura CORBA.
        • Proporciona transparencia entre los clientes y las implementaciones de los objetos.
        • Cuando un cliente invoca una operación, ORB busca la implementación del objeto, lo activa si es necesario, transmite la petición y devuelve la respuesta.
        • Permite conexión con otros ORBs.
    • 17/03/11 UNAP - Ing. Aldo Zanabria Componentes primarios en CORBA (II)
      • ORB Interface :
        • Interfaz de comunicación con el ORB para solicitarle servicios al propio ORB: conversión de referencias de objetos a cadenas, ...
      • IDL stubs (cabos) :
        • El stub es la interfaz que ve el cliente
        • Representante del servidor en el lado cliente (proxy)
        • Realiza invocación remota
        • Define rutinas específicas para operaciones particulares en objetos particulares
        • Definido en IDL y se transforma al lenguaje de programación del Cliente
        • La transformación entre CORBA IDL y el lenguaje de programación se realiza automáticamente por el IDL compiler
      • IDL skeletons (esqueletos) :
        • Ofrece una interfaz estática a cada servicio del objeto
        • Definido en IDL y se transforma al lenguaje de programación del Servant
    • 17/03/11 UNAP - Ing. Aldo Zanabria Componentes primarios en CORBA (III)
      • Dynamic Invocation Interface :
        • Permite la construcción dinámica de invocaciones a objetos.
        • No llama a una rutina específica para una operación particular en un objeto particular.
        • El cliente especifica el objeto a ser invocado, la operación y el conjunto de parámetros (esto lo obtiene del Interface Repository)
      • Dynamic Skeleton Interface :
        • Permite el manejo dinámico de las invocaciones a objetos.
        • No es accedido por un esqueleto específico para una operación determinada.
        • Se proporciona acceso a través de un nombre de operación y parámetros.
    • 17/03/11 UNAP - Ing. Aldo Zanabria Componentes primarios en CORBA (IV)
      • Object Adapter :
        • Conecta al ORB con la implementación del objeto para realizar los servicios que el ORB proporciona (a otros objetos y clientes):
          • generación e interpretación de referencias a objetos
          • invocación de métodos
          • seguridad de las interacciones
          • activación y desactivación del objeto y su implementación
          • mapeo de las referencias de los objetos a sus implementaciones
          • registro de implementaciones.
    • 17/03/11 UNAP - Ing. Aldo Zanabria Componentes primarios en CORBA (V)
      • Interface Repository :
        • Almacena información relativa a las interfaces IDL definidas en el Sistema Distribuido.
        • El ORB solicita los servicios al IR para:
          • comunicarse con otros ORB de distinta implementación.
          • verificar los parámetros de la petición
          • verificar la existencia de ciclos en los grafos de herencia
        • Los clientes solicitan los servicios al IR para:
          • navegar por la lista de interfaces
          • facilitar la instalación y distribución de objetos
        • Un ORB puede tener varios IR según la necesidad (prueba, release, externos, ...
      • Implementation Repository :
        • Almacena información de administración de cada uno de los objetos: cuáles están instanciados, como activarlos, permisos, etc.
    • 17/03/11 UNAP - Ing. Aldo Zanabria Conclusiones
      • Independiente del Sistema Operativo y del lenguaje de programación
      • Intenta hacer transparente a los programadores todos los aspectos que sea posible.
      • Facilita la reutilización de software, incluso cuando no esté implementado en un OOL.
      • Incorpora mecanismos de seguridad: autentificación, encriptación,...
      • Tecnología OO.
      • Estándar comercial y abierto.
      • CORBA 3.0 Modelo de componentes (CCM)
    • 17/03/11 UNAP - Ing. Aldo Zanabria Seguridad en el SID. INTERNET E INTRANET
    • OBJETIVOS
      • Identificar problemas de seguridad en los SID.
      • Estudiar las características de los cortafuegos y aprender a seleccionarlos.
      • Funciones de los cortafuegos en Internet e Intranet.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • 17/03/11 UNAP - Ing. Aldo Zanabria ÍNDICE 1. Riesgos y amenazas. 2. El cortafuegos. 3. Administración de cortafuegos. 4. Políticas de seguridad.
    • 17/03/11 UNAP - Ing. Aldo Zanabria MODELO DE RED CORPORATIVA
    • FACTORES DE RIESGO
      • Tipos de activos a proteger (datos confidenciales, programas susceptibles de sufrir sabotajes).
      • Probabilidad de sufrir un ataque: conocimiento de la posibilidad de existencia de entidades ajenas intrusas.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • MECANISMOS PARA LA VALORACIÓN DE RIESGOS
      • Equipos de “tigres”: ataques simulados.
      • Sesiones creativas de especialistas.
      • Procesos de ingeniería de seguridad de sistemas: análisis de la arquitectura, identificación de amenazas, integración de la protección.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • RIESGOS EN LA INTRANET 17/03/11 UNAP - Ing. Aldo Zanabria
    • RIESGOS EN INTERNET 17/03/11 UNAP - Ing. Aldo Zanabria
    • VALORACIÓN DE RIESGOS
      • Confidencialidad de mis datos.
      • Atractivo de activos.
      • Características de mi conexión Internet.
      • Características de mis routers.
      • Presupuesto de seguridad.
      • Uso de la criptografía.
      • Valorar el nivel de nuestro personal informático.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • EL CORTAFUEGOS
      • Definición: medio de regulación del acceso a la red de ordenadores de una organización mediante el control de accesos y el registro de actividades.
      • Función principal: limitar acceso a la Intranet filtrando los paquetes entrantes (por medio de la información que contienen).
      17/03/11 UNAP - Ing. Aldo Zanabria
    • CARACTERÍSTICAS DEL CORTAFUEGOS
      • Registro de actividades: información de sesiones (paquetes, fecha).
      • Sistema de aviso de intrusiones.
      • Ubicado de tal forma que las comunicaciones pasen a través suyo.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • UBICACIÓN DE CORTAFUEGOS 17/03/11 UNAP - Ing. Aldo Zanabria
    • TIPOS DE CORTAFUEGOS
      • Filtrado de paquetes: generalmente, routers. Se hace a nivel de red (poco seguros).
      • Gateways a nivel de aplicación: programas. Las conexiones se canalizan a través de aplicaciones proxy.
      • Híbridos: combina los dos anteriores.
      • Host bastión: arquitectura más que tipo de cortafuegos. Aisla la LAN.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • ¿CÓMO SE FILTRAN LOS PAQUETES?
      • Se especifican reglas de filtrado, y acciones asociadas a ellas.
      • En ellas consta: número de regla, dirección origen, destino, protocolo, puerto origen y destino y acción.
      • Importante: el orden de las reglas.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • FILTROS SOFTWARE
      • Filtrado de sesiones:
      • se realiza generalmente en el kernel del S.O.
      • Una sola regla para cada sesión.
      • Aplicaciones Proxy:
      • programas que se sitúan en el cortafuegos y actúan en representación del usuario.
      • Conexiones: directa, cliente modificado y proxy invisible.
      • Desventaja: una aplicación por servicio
      17/03/11 UNAP - Ing. Aldo Zanabria
    • AUTENTIFICACIÓN DE USUARIOS
      • Contraseñas: un solo uso (cambia cada sesión por algoritmos criptográficos) y uso múltiple (pueden ser “pinchadas”).
      • Tarjetas inteligentes o llaves (autentificadores manuales): se solicita palabra de paso y clave, y se devuelve contraseña.
      • Huellas dactilares y modelos de retina.
      • Problema de todos ellos: secuestros de sesión. Solución: autentificación de paquetes.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • ADMINISTRACIÓN DEL CORTAFUEGOS
      • Mantener las cuentas de usuarios.
      • Actualizar permisos de acceso a hosts.
      • Reaccionar ante alarmas.
      • Revisar registros de actividad.
      • Hacer copias de seguridad de los datos del cortafuegos.
      • Mantenimiento del sistema del cortafuegos.
      • Información sobre tecnología de ataques.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • TRAMPAS Y CEBOS
      • Sirven para atraer atacantes sospechosos.
      • Determinar tipos de acceso intrusos.
      • Crear entorno ficticio y legal (avisar al usuario que está accediendo a la red).
      • Obtener información para demandar al atacante (tener cuidado con no transgredir la ley nosotros).
      17/03/11 UNAP - Ing. Aldo Zanabria
    • RESPUESTA A UN ATAQUE (1)
      • Mantener la calma (normalmente es inofensivo).
      • ¿Interrumpimos el ataque?.
      • Sí: destruir la conexión y desconectar el cortafuegos.
      • No: detectar al intruso (leer registro de auditoría, obtener lista de routers hasta el intruso, identificar usuarios actuales).
      17/03/11 UNAP - Ing. Aldo Zanabria
    • RESPUESTA A UN ATAQUE (Y 2)
      • Una vez finalizado el ataque:
      • Determinar los cambios a efectuar en la política de seguridad.
      • Documentar detalles del ataque.
      • Informar al proveedor del cortafuegos, y a las autoridades (si procede).
      17/03/11 UNAP - Ing. Aldo Zanabria
    • POLÍTICA DE SEGURIDAD
      • Definición: especificación de los requisitos de control de acceso a la información y otros activos de una organización, determinando el tipo de acceso (consulta, modificación, borrado, descarga etc.) y quiénes lo realizan.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • TIPOS DE POLÍTICAS DE SEGURIDAD
      • Política de acceso en el ámbito de los servicios: define los requisitos de control de acceso a usuarios. (Alto nivel).
      • Política de acceso en el ámbito de implementación de la red: definición de las reglas de filtrado del cortafuegos. (Bajo nivel).
      17/03/11 UNAP - Ing. Aldo Zanabria
    • POSIBLES PROBLEMAS
      • Suponen un retraso en la implantación de las protecciones en la red.
      • Burocracia: entran en los trabajos cotidianos de operación del sistema.
      • Hay que velar por el cumplimiento de la política para que sea efectiva.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • REQUISITOS PARA UNA CORRECTA POLÍTICA
      • Determinar permisos para servicios de entrada (TELNET, correo etc.)
      • Determinar permisos para servicios de salida (WWW, FTP etc.)
      • Determinar requisitos de auditoría: disminuyen rendimiento de la red.
      • Elegir herramienta de administración.
      • Requisitos para cebos y trampas: no salirse de la ley.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • EJEMPLO (1)
      • Propuesto por Ed Amoroso y Ron Sharp.
      • a) Puntos principales de contacto (personas).
      • b) Registro de modificaciones (versiones de la política).
      • c) Ámbito de los requisitos: definición de la red.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • EJEMPLO (Y 2)
      • d) Clasificación de la información de la empresa (abierta, propietaria y propietaria restringida).
      • e) Clasificación de las redes de la empresa: abierta, propietaria y propietaria - restringida.
      • f) Servicios del cortafuegos: acceso o no a Telnet, FTP, EMAIL, WWW.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • REAL DECRETO 994/1999, de 11 de junio (B.O.E. 25.06.1999)
      • http://www.igsap.map.es:80/cia/dispo/rd994-99.htm
      • Establece 3 niveles de seguridad:
        • a) BÁSICO: datos de carácter personal
        • b) INTERMEDIO: datos de infracciones administrativas, penales, servicios financieros, o personales que permitan evaluación de personalidad del individuo.
        • c) ALTO: datos de ideología, religión, creencias, raza, salud, vida sexual y política.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • REAL DECRETO 994/1999. Requisitos
      • Nivel BÁSICO:
        • Documento de seguridad con la normativa básica.
        • Mecanismos de actualización y revisión de la normativa.
        • Documento de funciones y obligaciones del personal.
        • Medidas para informar al personal sobre la normativa.
        • Registro de incidencias.
        • Relación de usuarios y procedimientos de identificación y autentificación.
        • Renovación periódica de contraseñas y almacenamiento ininteligible.
        • Mecanismos para evitar intrusiones no autorizadas.
        • Control de soportes (inventario).
        • Control de salidas de soportes.
        • Copias de respaldo, al menos semanalmente.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • REAL DECRETO 994/1999. Requisitos (2)
      • Nivel INTERMEDIO:
        • Todo el básico.
        • Documento de seguridad ampliado.
        • Designación de responsables de seguridad.
        • Consignación de recuperaciones en incidencias.
        • Autorización escrita del responsable para recuperar ficheros.
        • Identificación unívoca de usuarios.
        • Limitación de accesos no autorizados reincidentes.
        • Control de acceso físico.
        • Registro de entrada y salida de soportes.
        • Mecanismo para impedir recuperaciones de información almacenada en soportes.
        • Auditorías informáticas cada 2 años.
        • Pruebas con datos ficticios.
      17/03/11 UNAP - Ing. Aldo Zanabria
    • REAL DECRETO 994/1999. Requisitos (y 3)
      • Nivel ALTO:
        • Todo el intermedio.
        • Copias de respaldo y recuperación fuera de las instalaciones de equipos informáticos.
        • Cifrado de la información de los soportes.
        • Registro de accesos.
        • Informe mensual de revisiones y problemas detectados.
        • Transmisión cifrada de datos.
      17/03/11 UNAP - Ing. Aldo Zanabria