Sistemasdeinformacindistribuidos 110317175548 Phpapp01 PDF

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 1

Arquitectura
Cliente/Servidor

Justificación Cliente/Servidor
ANTES AHORA
AVANCE • Rigidez. • Múltiples
TECNOLÓGICO • No redistribución. procesadores
• Vinculación al sistema. • Portabilidad entre
• Solapamiento, procesadores.
duplicación y • Migrabilidad entre
redundancia. plataformas.
EXIGENCIAS • Producción masiva. • Competencia.
DE LA • Tareas simples. • Renovación.
EMPRESA • Repetitivas. • Factor tiempo crítico.
• Desmotivación. • Autonomía.
• Usuario operador. • Usuario analista.
ENTORNO • Adaptación a la • Software a medida.
GENERAL capacidad del • Ordenadores
ordenador. accesibles.
• Ordenadores caros. • Domesticación de la
• Usuarios asustadizos. informática.

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.

Implicaciones del modelo
Cliente/Servidor
N e c e s id a d e s c o m e r c ia le s e n c o n t in u a e v o lu c ió n
N u e v o s r o le s d e S is t e m a s d e I n fr a e s t r u c t u r a A b ie r t a
I n fo r m a c ió n y d e lo s u s u a r io s C lie n t e / S e r v id o r
N u e v a s h e r r a m ie n t a s d e d e s a r r o llo :
P r o t o t ip o s
N u e v o p r o c e s o d e d e s a r r o llo

¿Cuándo implantar C/S?
 Cambios estructurales y organizativos.

 Cambios en organigramas.
 Respuesta dinámica de mercado.
 Cambio en procesos de negocio.

¿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.

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.

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.

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.

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.

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.

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.

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.

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.

Evolución (III)
 EL FUTURO.
 Facilidad de uso de las aplicaciones.
 Accesos a datos distribuidos en cualquier lugar del mundo
(y del espacio).

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.

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.

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.

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.
Presentación Negocio Datos
C S
Modelos C/S (II)
 Función distribuida
 Máxima flexibilidad.
 Lógicas de negocio separadas.
Presentación Negocio Negocio Datos
C S

Modelos C/S (III)
 Datos distribuidos
 Ficheros distribuidos.
 Bases de datos distribuidas.
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.

Aplicaciones de 2 y 3 niveles (II)
 3 niveles:
 Modelo presentación-negocio-datos
 Distribución flexible.
 Sistema abierto. No dependiente.
C
C Negocio
C

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”

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.

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.

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.

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.

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.

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.
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.

Ejercicios:

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?

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é?

CONSIDERACIONES:
Aspectos a considerar, tendencias,

Desarrollo web, nuevos tipos de
dispositivos.

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

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
 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.

 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
 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 (**)

 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
 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

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

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

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
17/03/11  Permite fácil, flexible
UNAP -y eficiente
Ing. Aldo Zanabria integración con BBDD 46
Desarrollos Web
Navegador
 Esquema general
HTTP
Parámetros Web Server

proceso
Procesos CGI
Servidor CORBA Conector

CORBA CORBA
Base de RMI Máquina virtual

Servlet Java
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

 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

 Tendencia actual
Navegador Móvil Usuario
http Wml binario
Gestor
Web Server WAP Server comunicaciones
- -
Páginas HTML Páginas WML Interface de usuario
XML
Servidor Aplicaciones Lógica de negocio
SQL
Datos
Base de datos

 Variante de los fabricantes BBDD
http Wml binario
Gestor
- -
Páginas HTML Páginas WML Interface de usuario
XML
Lógica de negocio
Base de datos Datos

 Variante de los fabricantes pasarelas
http Wml binario
Gestor
- -
Reglas de
Interface de usuario
traducción WML
Interface de usuario
Páginas HTML
Lógica de negocio
SQL
Datos
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

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.

Tecnología de objetos
distribuidos y arquitectura de
componentes.

Índice
1. Introducción.
2. OMA (Object Management Architecture).
3. CORBA (Common Object Request Broker

Architecture).
4. Conclusiones.

Introducción
Evolución de la arquitectura de los sistemas informáticos
C/S 2 capas
C/S 3 capas
Presentación
Sistemas monolíticos Presentación
Negocio
Presentación
Negocio Negocio
Negocio
Datos
Datos
Datos
BD

Arquitectura multicapa
subcapas
Presentación
Negocio
Datos
BD

Arquitectura de componentes (I)
(multicapa y 3-tier)
3:Component system
2:Component frameworks
1:Components
( tier ≈ grada )
 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.
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

Arquitectura de componentes (III)
 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 (IV)
 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, ...

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)

OMA: Objetivos técnicos
 Transparencia distribución  Mantenimiento de

 Rendimiento local y versiones
remoto  Notificación de eventos
 Comportamiento dinámico  Semántica de Relaciones
 Sistema de nombrado entre objetos
 Consultas: nombre,  API en C para todas las
atributos, relaciones operaciones
 Control de la concurrencia  Administración y gestión
 Transacciones  Internacionalización
 Robustez, disponibilidad  Estandarización

Arquitectura del modelo de referencia OMA
Application CORBA
objects facilities
CORBA 2.0 Object Request Broker (ORB)
Object services
(CORBAservices)
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

17/03/11
Externalization serviceUNAP
: Permite copiar objetos por valor
- Ing. Aldo Zanabria 66
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.
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

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

CORBA
(Common Object Request Broker Architecture)
 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
C C++ Java Delphi Ada SmallTalk
IDL
Object Request Broker (ORB)

Comunicación C/S en CORBA
Cliente Servidor
Invocation Object
Interface Adapter

Arquitectura de CORBA
Interface Implementation
IDL COMPILER
Repository Repository
operación(args
OBJ )
REF Object
Client
resultado(args) (Servant)
IDL Dynamic
Object
Static Skeleton
Dynamic Adapter
IDL ORB Skeletons Interface
Invocation
Stubs Interface
Interface

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.
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

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.

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.

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.

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)

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.

ÍNDICE
1. Riesgos y amenazas.
2. El cortafuegos.
3. Administración de cortafuegos.
4. Políticas de seguridad.

MODELO DE RED CORPORATIVA
Acceso Acceso INTERNET
desde
INTRANET Internet
a
Internet
Subred secundaria Red principal
Host
Servidor
Router
Hub
Red Ethernet topología bus
Puestos de la subred Puestos de la red principal

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.

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.

RIESGOS EN LA INTRANET
Suplantación del
superusuario
Host AGRESIÓN
Ataques
externos Gateway
Dańos físicos y
AGRESIÓN accesos no autorizados
Hub
AGR
ESI
ÓN
N
ESIÓ
R
AG
Suplantación
de usuarios
Puestos de la red principal

RIESGOS EN INTERNET
WWW:
INTERNET
Ejecución de programas remotos
Transferencias de soft. dudoso
Accesos a nuestros datos
AG
RE
SI
ON
ES
Transferencias
FTP con virus Host
Correo:
Captura de mensajes
Gateway
Inundación
Inclusión de "Caballos de Troya"
Hub
Aspiración de paquetes
Suplantación de direcciones IP
desde el exterior
PRINCIPAL SOLUCIÓN: CORTAFUEGOS

Puestos de la red principal

VALORACIÓN DE RIESGOS
 Confidencialidad de  Presupuesto de
mis datos. seguridad.
 Atractivo de activos.  Uso de la criptografía.
 Características de mi  Valorar el nivel de
conexión Internet. nuestro personal
 Características de mis informático.
routers.

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).

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.

UBICACIÓN DE
CORTAFUEGOS
Acceso Acceso INTERNET
INTRANET desde a
Internet Internet
Cortafuegos
Subred secundaria Red principal
Host
Servidor
Router
Cortafuegos Cortafuegos
Hub
Red Ethernet topología bus
Puestos de la subred Puestos de la red principal

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.
¿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.

FILTROS SOFTWARE
Filtrado de sesiones: Aplicaciones Proxy:
 se realiza generalmente  programas que se sitúan
en el kernel del S.O. en el cortafuegos y

 Una sola regla para cada
actúan en
representación del
sesión.
usuario.
 Conexiones: directa,
cliente modificado y
proxy invisible.
 Desventaja: una
aplicación por servicio

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.

ADMINISTRACIÓN DEL
CORTAFUEGOS
 Mantener las cuentas  Hacer copias de
de usuarios. seguridad de los datos
 Actualizar permisos de del cortafuegos.
acceso a hosts.  Mantenimiento del
 Reaccionar ante sistema del
alarmas. cortafuegos.
 Revisar registros de  Información sobre
actividad. tecnología de ataques.

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).

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).

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).

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.

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).

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.

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.

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.

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.

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.

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.
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.
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.

Sistemasdeinformacindistribuidos 110317175548 Phpapp01 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sistemasdeinformacindistribuidos 110317175548 Phpapp01 PDF

Cargado por

Copyright:

Formatos disponibles

Sistemas de Información

Ing. Aldo Zanabria Gálvez

17/03/11 UNAP - Ing. Aldo Zanabria 1

17/03/11 UNAP - Ing. Aldo Zanabria 2

17/03/11 UNAP - Ing. Aldo Zanabria 3

17/03/11 UNAP - Ing. Aldo Zanabria 4

17/03/11 UNAP - Ing. Aldo Zanabria 5

 Cambios estructurales y organizativos.

17/03/11 UNAP - Ing. Aldo Zanabria 6

 La demanda de sistemas fáciles.

17/03/11 UNAP - Ing. Aldo Zanabria 7

Definición: Sistema distribuido entre múltiples

Separa los servicios situando cada uno en su

17/03/11 UNAP - Ing. Aldo Zanabria 8

17/03/11 UNAP - Ing. Aldo Zanabria 9

17/03/11 UNAP - Ing. Aldo Zanabria 10

17/03/11 UNAP - Ing. Aldo Zanabria 11

17/03/11 UNAP - Ing. Aldo Zanabria 12

 ODBC: (Open DataBase Conectivity) (Microsoft).

 JDBC: (Java DataBase Conectivity) (Java).

17/03/11 UNAP - Ing. Aldo Zanabria 13

 CORBA (Common Object Request Broker Architecture) (Object

17/03/11 UNAP - Ing. Aldo Zanabria 14

17/03/11 UNAP - Ing. Aldo Zanabria 15

17/03/11 UNAP - Ing. Aldo Zanabria 16

 Conecta procesos para constituir aplicación.

17/03/11 UNAP - Ing. Aldo Zanabria 17

17/03/11 UNAP - Ing. Aldo Zanabria 18

 Entorno de aplicaciones incremental.

 Integración: por la GUI.

17/03/11 UNAP - Ing. Aldo Zanabria 19

Presentación Negocio Datos

Presentación Negocio Negocio Datos

17/03/11 UNAP - Ing. Aldo Zanabria 21

Presentación Negocio Datos

17/03/11 UNAP - Ing. Aldo Zanabria 22

17/03/11 UNAP - Ing. Aldo Zanabria 23

17/03/11 UNAP - Ing. Aldo Zanabria 24

 Definición según IEEE:

17/03/11 UNAP - Ing. Aldo Zanabria 25

17/03/11 UNAP - Ing. Aldo Zanabria 26

 Definición: “Conjunto de reglas, definiciones y propiedades

17/03/11 UNAP - Ing. Aldo Zanabria 27

17/03/11 UNAP - Ing. Aldo Zanabria 28

17/03/11 UNAP - Ing. Aldo Zanabria 29

17/03/11 UNAP - Ing. Aldo Zanabria 30

17/03/11 UNAP - Ing. Aldo Zanabria 32

17/03/11 UNAP - Ing. Aldo Zanabria 33

a) ¿Podríamos estar ante un sistema distribuido?

17/03/11 UNAP - Ing. Aldo Zanabria 34

2) Supongamos la misma empresa del ejercicio 1

17/03/11 UNAP - Ing. Aldo Zanabria 35

Aspectos a considerar, tendencias,

17/03/11 UNAP - Ing. Aldo Zanabria 36

17/03/11 UNAP - Ing. Aldo Zanabria 37

 Middleware. Es la herramienta o conjunto de

17/03/11 UNAP - Ing. Aldo Zanabria 39

17/03/11 UNAP - Ing. Aldo Zanabria 41

 Middleware -> Información a transmitir + Sobrecoste en

ancho de banda + Sobrecoste en tiempo de proceso

referencias del fabricante

17/03/11 UNAP - Ing. Aldo Zanabria 43

17/03/11 UNAP - Ing. Aldo Zanabria 44