Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Sistemas distribuidos2

235 views

Published on

  • Be the first to comment

  • Be the first to like this

Sistemas distribuidos2

  1. 1. SISTEMASSISTEMAS DISTRIBUIDOSDISTRIBUIDOS NOMBRE: CARLOS CARVAJAL HOLGER SANCHEZ CURSO: 8vo SISTEMAS 2013-2014
  2. 2. ¿Nos situamos?¿Nos situamos? La generalización del termino cloud computing, la popular nube, como paradigma de todo tipo, tanto organizativo como de diseño de sistemas, comporta una interesante reflexión.
  3. 3. SISTEMA DISTRIBUIDOSISTEMA DISTRIBUIDO Un sistema distribuido es un sistema de información en el cual las funciones se reparten por áreas de trabajo diferentes que trabajan de forma coordinada para asumir los objetivos que la organización asigna a ese sistema de información. Esta definición no obliga a que los servicios sean internos ni fabricados por la propia organización.
  4. 4. Arquitecturas en un sistemaArquitecturas en un sistema distribuido.distribuido. Esta constatación de la realidad no resulta extraña si acudimos a la definición que ANSI/IEEE hace del término: “Arquitectura es la organización fundamental de un sistema, donde se integran sus componentes, se establecen las relaciones e interdependencias entre esos componentes y su entorno y se establecen los principios para su diseño, gestión y evolución”.
  5. 5. La Perspectiva de NegociosLa Perspectiva de Negocios (Business Perspective).(Business Perspective). Describe como trabaja la compañía. Incluye las relaciones con terceros y los planes de evolución desde el estado actual al objetivo deseado.
  6. 6. Son componentes clásicos de la perspectiva de negocio:  Los procesos de negocio.  Los Manuales de Procedimientos.  Objetivos a corto, medio y largo plazo.  Las estructuras organizativas y sus condicionamientos.  Las funciones de negocio que se realizan.  Las relaciones entre estos componentes.  Los organigramas de la empresa, etc.
  7. 7. La Perspectiva de la InformaciónLa Perspectiva de la Información (Information Perspective).(Information Perspective).  Define que necesita saber la organización para funcionar.  Son componentes clásicos de la perspectiva de información:  Mapas de procesos.  • Modelización de los procesos.  • Reglas de negocio.  • Modelo conceptual de datos.  • Integración de datos y procesos.  • Descripción de procesos dentro de un marco SOA.  • Diseño de los procesos dentro de aplicaciones distribuidas SOA..  • Mapa de eventos-respuestas.
  8. 8. La Perspectiva de AplicaciónLa Perspectiva de Aplicación (Aplication Perspective).(Aplication Perspective). Define las aplicaciones de la empresa.
  9. 9. La Perspectiva de GestiónLa Perspectiva de Gestión (Management Perspective).(Management Perspective). Define los condicionamientos de gestión y administración de toda la plataforma distribuida. Aunque su contenido es muy amplio, son componentes clásicos de la perspectiva de gestión:  Lugares donde existe administración informática.  Condicionamientos organizativos.  Políticas de soporte a usuario.  Gestión de adquisición de recursos.  Horarios de disponibilidad.  Políticas de medición y análisis de rendimientos, etc.
  10. 10. La Perspectiva TecnológicaLa Perspectiva Tecnológica (Techology Perspective).(Techology Perspective). Propone el software básico, el hardware, las redes y las comunicaciones que soportan el sistema distribuido y por tanto a la organización. Son componentes clásicos de la perspectiva tecnológica:  Hardware y software básico de los puestos clientes y de los puestos servidores.  Estándares adoptados por la organización  Recursos de impresión.  Ofimática.  PDA’s y telefonía móvil, etc…
  11. 11. Relación entre las perspectivas.
  12. 12. Las Arquitecturas de AplicaciónLas Arquitecturas de Aplicación Clásicas: Batch y TransaccionalClásicas: Batch y Transaccional Estas arquitecturas “de siempre” siguen perfectamente vivas y son de gran utilidad en las aplicaciones distribuidas. Hay que conocerlas y usarlas cuando y donde la funcionalidad y la organización del sistema distribuido las necesite.
  13. 13. Arquitectuta BatchArquitectuta Batch Una arquitectura Batch se basa en la ejecución en cadena secuencial de varios programas que cubren una función dentro de la aplicación. La arquitectura Batch ha de proporcionar:  Recursos para definir el flujo de la cadena, recurso de programación implementado en:  Un lenguaje de definición del flujo.  Parámetros:  Filtro y configuración del proceso. Por ejemplo, el periodo de fechas a tratar.  Control del flujo de la ejecución.
  14. 14.  Un mecanismo de petición y ejecución, denominado por razones históricas  por su nombre en los Mainframe, el Remote Job Control (RJC). Aporta  varios tipos de recursos:  Un mecanismo de petición con: Una cola de los procesos pendientes de ejecución con un  mecanismo de anotación y de consulta desde el exterior del  estado de ejecución. La cola necesita un mecanismo de  prioridades y clientes VIP. Un gestor RJE que consultando la cola inicia cada uno de los  procesos anotados.
  15. 15. ArquitecturaArquitectura
  16. 16. Utilidad de la Arquitectura Batch.Utilidad de la Arquitectura Batch.  Incremento de la productividad por la planificación y el solape de tareas  Optimización de recursos distribuyendo la carga sobre ellos uniformemente en  el tiempo.  Automatización de tareas administrativas repetitivas.  Automatización de las tareas que suponen necesidad de altos conocimientos.  Disminución de errores por operatorias erróneas.  Análisis de incidencias a posteriori por expertos.  Localizar en el tiempo las tareas que hay que hacer en momentos  determinados.  Sincronizar tareas evitando que un operador haya de estar pendiente de ello.  Adaptabilidad a la carga de trabajo..  Y un largo etcétera.
  17. 17. La arquitectura transaccional.La arquitectura transaccional. La arquitectura transaccional apareció en los primos momentos de la informática comercial por la necesidad de optimizar los recursos de proceso en un momento en que eran un bien escaso.
  18. 18. La búsqueda de los OrígenesLa búsqueda de los Orígenes CUAL ES EL NOMBRE DE CADA COSA? Esta pregunta tan simple, tiene para nosotros los informáticos una respuesta muy compleja y en algunos casos casi imposible. Cuando uno consulta documentación informática de cualquier tipo, se encuentra con un lío terminológico sencillamente increíble. Las mismas cosas se llaman de forma diferente, cosas diferentes se llaman igual y cosas que no tienen nada que ver con la Informática se incluye dentro de la documentación informática como conceptos básicos.
  19. 19. El lío terminológico.El lío terminológico.  Personalmente creo que hasta el lío es clasificable. Yo aprecio tres grupos.  El lío funcional.  Dentro de la especificación funcional de sistemas y de sus posibles  soluciones aparecen conceptos como:  Proceso corporativo.
  20. 20.  Proceso departamental.  Hace referencia a que el  proceso informático sólo  afecta a un departamento.  Como en el caso anterior, es  un término más organizativo  que informático.  Proceso cooperativo.  Es un concepto que hace referencia a que dos o más elementos  colaboran realizando una única tarea repartiéndose el trabajo. Proceso  claramente de diseño distribuido y fundamental en nuestro viaje.  Reingeniería.  Es un término muy genérico aplicado a aquellos trabajos informáticos  desarrollados para adaptar sistemas antiguos a las nuevas tecnologías  y/o necesidades.

×