parte_12.txt

Arquitectura SOA TEMARIO OPOSICIONES COIICV | TEMA 25 13 Es evidente que cualquier ecosistema necesita la de finición de responsabilidades, formas de acuerdo, derechos y seguridad: fundamentos básicos de cualquier ecosistema SOA. Pero estos fundamentos, también al igual que en el ejemplo de acuerdos...

Arquitectura SOA TEMARIO OPOSICIONES COIICV | TEMA 25 13 Es evidente que cualquier ecosistema necesita la de finición de responsabilidades, formas de acuerdo, derechos y seguridad: fundamentos básicos de cualquier ecosistema SOA. Pero estos fundamentos, también al igual que en el ejemplo de acuerdos empresariales, están condicionados por la confianza y riesgo de cada acuerdo, y por ta nto, no son iguales para todos. Por eso, las reglas de contratos se pueden adaptar o deberían se r adaptables a cada situación y participante y de forma evolutiva, con revisión de versiones, en f unción de la observación de evidencias que aporten consistencia a dicha evolución. A nivel estratégico, el ciclo de vida, o etapas en la implementación de un servicio, describe la última fase o culmen de la planificación global de los servicios. Esta planificación se ve en la Figur a 8 y comienza por la firma o aceptación del acuerdo de usuario (User Agreement) donde se plantean los términos del contrato de provisión del nuevo servicio en cuanto a propósito, coste, disponibilidad y certificaciones, entre otros. En l a segunda fase, se especifican y acuerdan los términos del servicio en cuanto a necesidades, func ionalidades, expectativas de prestación, capacidad, políticas, convergencias tecnológicas y semánticas y calidad del servicio, entre otros. La tercera fase se focaliza en la interfaz del serv icio y su integración en cada dominio. Finalmente, la cuarta fase desarrolla el ciclo de vida o etapas de implementación que ya hemos mencionado. Acuerdo de usuario Contrato Servicio Descripción Interface Mensajes Implementación Ciclo de vida de la implantación del servicio Figura 8. Fases en la planificación estratégica de servicios 3. Tecnologías de referencia Como se dijo en la introducción, la arquitectura SO A es un paradigma o un estilo TI empresarial. Por tanto, no podemos dar una tecnología o un proto colo que lo abarque plenamente. Al contrario, SOA requiere del uso combinado de varios protocolos para cubrir las expectativas de las distintas capas que hemos visto en la figura 6. A continuación vamos a nombrar algunos de los proto colos y lenguajes más utilizados en la implementación de arquitecturas SOA. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Sara Blanc Clavero 14 TEMARIO OPOSICIONES COIICV | TEMA 25 3.1. Creación de servicios Podemos mencionar multitud de lenguajes que nos van a permitir crear nuestros servicios. Por ejemplo, y entre muchos, JAX-WS es un conjunto de A PIs que permite crear y utilizar servicios web. Es compatible con SOAP (Simple Object Access P rotocol), protocolo a nivel de mensajería que veremos a continuación. También .Net soporta di ferentes protocolos de comunicación pero necesita combinarse con otros paquetes que permita interconectar servicios desarrollados en diferentes plataformas. Por ejemplo, se utiliza WCF , compatible con los estándares WS- y SOAP. 3.2. Conectividad entre servicios Protocolos de Servicios Web (WS-): son un conjunto de protocolos que se podrían integr ar en varias de las capas SOA. Este conjunto de protocolo s y estándares tienen una alineación muy clara con SOA ya que sirven para intercambiar datos en Internet entre aplicaciones independientemente (o transparente) al lenguaje de programación o plataforma sobre la que se ejecuten. Podemos encontrar más información en W3C (16) y en OASIS (17). Por ejemplo, es uso de contrato ya está establecido facilitando la desc ripción y descubrimiento del servicio. La intención de registro de servicios de SOA se alinea con UDDI (Universal Description, Discovery and Integration), con WS-Discovery y el formato WSDL (W eb Services Description Language). WSDL se combina con XML y a menudo con SOAP en la gestió n de mensajería. No confundamos SOA con SOAP. SOA es el término de referencia de la arq uitectura mientras que SOAP es un protocolo concreto de mensajería. Mensajería SOAP: se describe en la ISO/IEC 40210 Information techno logy de 2011 (segunda versión). Su éxito se basa en su potencial para sis temas descentralizados y distribuidos incluso con restricciones de recursos. SOAP utiliza el form ato XML creado por el W3C, que junto con otros formatos como JSON (más ligero), se están convirtie ndo en estándares de facto para conseguir la interoperabilidad entre sistemas. En modelos B2B ta mbién se incluye EDI o MFT. Otros protocolos que se absorben frecuentemente en SOA a nivel de co municaciones son HTTP, JMS, FTP, VSAM, CICS, Tuxedo y un largo etc. junto con protocolos W S- para soportar direccionamiento y seguridad, entre otros, ambos compatibles con el pr otocolo SOAP (WS-Addressing, WS- ReliableMessaging). Arquitectura REST : Conviene mencionar también la arquitectura REST. A diferencia de SOAP, REST es un estilo de arquitectura, no un protocolo . Se puede implementar utilizando cualquier protocolo que siga URI (Uniform Resource Identifier ). REST puede alinearse con SOA ya que también incluye el concepto de contrato cliente-ser vidor. Implementar REST, tal y como lo concibió su autor (ver el blog y referencias de Roy T. Field ing) puede ser complejo para el inexperto y se confunde a menudo con la implementación de interfac es (APIs) que utilicen HTTP. Sin embargo, combinar REST sobre HTTP puede ser un todo un acier to ya que HTTP proporciona seguridad y autenticación. La mensajería REST acepta cualquier formato (puede ser XML, JSON u otros), lo que lo hace más apropiado que SOAP (aunque sacrific ando ancho de banda) para trabajar con componentes con restricciones de memoria o procesam iento tales como sensores. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Arquitectura SOA TEMARIO OPOSICIONES COIICV | TEMA 25 15 3.3. Por encima de la capa de servicios Orquestación y coreografía: Como ejemplos tenemos las implementaciones basadas en BPEL (ej. WS-BPEL) para procesos orquestados y también encontramos ref erencias a herramientas BPM (18), o específicas de Oracle (SCA), IBM, Micro soft y un largo etc. Probablemente hay muchos más protocolos que se pued en integrar en una arquitectura SOA, pero aquí lo dejamos como un ejercicio de investigación y “descubrimiento” para el alumno. Referencias bibliográficas (1) Information technology – Reference Architectur e for Service Oriented Architecture (SOA RA) – Part 1: Terminology and concepts for SOA. (2) Information technology – Reference Architectur e for Service Oriented Architecture (SOA RA) – Part 2: Reference Architecture for SOA Solutions. (3) Information technology – Reference Architectur e for Service Oriented Architecture (SOA RA) – Part 3: Service Oriented Architecture ontology. (4) Service-Oriented Architecture: Concepts, Techno logy, and Design, Erl, T., (2014) 13ª edición. Ed Prentice Hall professional technical reference. (5) SOA Principles of Service Design, Erl, T., (200 7) 1ª edición. Ed Prentice Hall. (6) SOA Open Source, Davis, J., (2010). Ed Anaya mu ltimedia. (7) SOA Approach to Integration: XML, Web Services, ESB, and BPEL in real-world SOA projects, Juric, M.B., Loganathan, R., Sarang, P., Jennings, F., (2007). Ed Packt Publishing Birmingham-Mumbai. (8) Introduction to Service Oriented Architecture ( www.eu-orchestra.org) (2007). (9) Service-oriented modeling and architecture. How to identify, specify and realize services for your SOA, Arsanjani, A., (2004) IBM (ibm.com/redboo ks). (10) www.oracle.com/SOA (11) La arquitectura Orientada a Servicios (SOA) de Microsoft aplicado al mundo real (2006) Whilepapers Ed Microsoft. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Sara Blanc Clavero 16 TEMARIO OPOSICIONES COIICV | TEMA 25 (12) Technologies for SOA-based Distributed Large S cale Process Monitoring and Central Systems, Jammes, F., Bony, B., Nappey, P., Colombo, A.W., Delsing, J., Eliasson, J., Kyvsakov, R., Karnovskos, S., Stluka, P. Tilly, M., (2012) IECON 38th Annual Conference on IEEE Industrial Electronics Society Ed. IEEExplo re pp. 5799-5804. (13) Cloud Computing and SOA, Raines, G., (2009). S ervice-Oriented Architecture (SOA) Series, Ed Systems Engineering at MITRE. (14) 100 SOA Questions Asked and Answered, Holley, K., Arsanjani, A., (2001). Ed PEARSON, custom edition for IBM. (15) www.soaschool.com (16) World Wide Web Consortium www.w3c.es (17) OASIS www.oasis-open.org (18) Application Platform for SOA and BPM. Reiem, T ., (2007). Enterprise Technology Strategist, SOA and BPM. Microsoft Corporation (EMEA). Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019TEMARIO OPOSICIONES COIICV | TEMA 26 1 Tema 26. Concepto, evolución y tendencias de los sistemas operativos. Los sistemas UNIX y LINUX. Los sistemas Microsoft Windows. Los sistemas Android Vicente Sancho Guijarro Colegiado 0893 Los sistemas operativos son una parte esencial de c ualquier sistema informático. Este campo está cambiando muy rápidamente ya que las com putadoras se encuentran en multitud de contextos, aunque los conceptos fundame ntales siguen siendo bastante claros. Este capítulo intenta definir el concepto de sistem a operativo y su alcance, así como la situación de los sistemas operativos hoy en día. A continuación, se profundiza un poco más en los pr incipales sistemas operativos: Linux, Windows y Android. Para cada uno de ellos se empieza con una breve contextualización, resumiendo su historia y de dónd e vienen, para luego entrar en algunos detalles de sus características. Estos sist emas operativos continúan evolucionando con nuevas versiones, pero mantienen las bases sobre las que están desarrollados. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Vicente Sancho Guijarro 2 TEMARIO OPOSICIONES COIICV | TEMA 26 1. Concepto, evolución y tendencias de los sistemas operativos 1.1. Concepto Un sistema operativo es un programa que se encarga de administrar el hardware (procesadores, memoria principal, discos, pantalla y otros disposi tivos de entrada/salida) de una computadora. También proporciona las bases para los programas de aplicación ofreciendo un conjunto abstracto de recursos simples y actúa como intermediario entr e el usuario y la computadora, optimizando el uso de estos componentes. Básicamente, ofrecen una forma razonable de resolver el problema de crear un sistema informático utilizable, permitiend o ejecutar programas de usuario. Sin embargo, no existe ninguna definición universal mente aceptada sobre qué forma parte de un sistema operativo, ya que se puede encontrar una gr an variedad de sistemas operativos en los cuales varían enormemente sus características. Teniendo esto en cuenta, otra definición común, es que un sistema operativo es aquel programa que se ejecuta continuamente en la computadora, usu almente llamado kernel, siendo todo lo demás programas del sistema y de aplicación. La figura 1 representa el papel que juega el sistem a operativo en el funcionamiento de la computadora. Éste se sitúa entre la capa de hardwar e y la de aplicaciones del usuario. En la capa inferior se encuentra el hardware (procesador, tarj etas, discos, teclado, ratón, pantalla, etc.), el cual es controlado por el sistema operativo, ejecut ándose en modo kernel o supervisor. En este modo, se tiene acceso completo a todo el hardware, así como a todo el conjunto de instrucciones que la máquina sea capaz de ejecutar. Figura 1: Ubicación del sistema operativo Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Concepto, evolución y tendencias de los sistemas op erativos TEMARIO OPOSICIONES COIICV | TEMA 26 3 Por el otro lado, el sistema operativo -el cual ya forma parte del software- se comunica con las aplicaciones del sistema y con las del usuario, tod o ello en modo usuario, con un conjunto de instrucciones más limitado y que no comprometan al sistema operativo. Sin embargo, algunas aplicaciones del sistema pueden tener privilegios p ara ejecutar algunas instrucciones del modo kernel, como podría ser una aplicación para cambiar la contraseña del usuario. Es una operación crítica y que requiere cierta protección, por lo ta nto, está acción la llevará a cabo con una llamada en modo kernel. Esta distinción entre modo kernel o supervisor y mo do usuario no es algo tajante ya que depende del sistema operativo de dónde ponga la frontera. D e hecho, suelen incluir muchas veces un shell (consola con la que el usuario interactúa en modo t exto) o GUI (Graphical User Interface: iconos, ventanas, etc.), los cuales se ejecutan en modo usu ario, al igual que las aplicaciones que el usuario lanza desde ellos. 1.1.1. Tipos de sistemas operativos según su entorn o Desde los primeros sistemas operativos, han ido evo lucionando y apareciendo distintos tipos de sistemas operativos, según el propósito para el cua l estuvieran destinados. A continuación, se describen algunos de los principales tipos, aunque algunos sistemas operativos pueden pertenecer a más de un tipo si se pueden desenvolver en varios escenarios con características distintas. • Sistemas operativos de mainframe. Las computadoras mainframe son aquellas del tamaño de una sala entera que aún se encuentran en los pri ncipales centros de datos corporativos. Están profundamente orientados hacia el procesamien to de muchas tareas a la vez, las cuales requieren muchas operaciones de E/S. Ejemplos: OS/390 y algunas variantes de UNIX. • Sistemas operativos de servidores. Se suelen ejecut ar en computadoras potentes, estaciones de trabajo o incluso en mainframes, los cuales dan servicio a varios usuarios a la vez a través de una red y les permiten compartir recursos hardware y software. Algunos de estos servicios podrían ser:
Servicio de impresión.
Servicios de ficheros.
Servicio web.
Etc. Ejemplos: Solaris, FreeBSD, Linux, Windows Server 2 00x. • Sistemas operativos de multiprocesadores. Están ori entados a maximizar el poder de cómputo conectando varias CPU en un solo sistema, p or lo tanto, poseen características especiales de comunicación, conectividad y consiste ncia. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Vicente Sancho Guijarro 4 TEMARIO OPOSICIONES COIICV | TEMA 26 Hoy en día, al ser muy común el uso de chips multin úcleo, la mayoría de sistemas operativos ya lidia con estas características, aunq ue sea a menor escala que los sistemas especializados. Ejemplos: Linux, Windows. • Sistemas operativos de computadoras personales. Su propósito es proporcionar un buen soporte para un solo usuario de manera simultánea. Son los más populares, siendo utilizados tanto en computadoras de sobremesa como en portátiles. Ejemplos: Linux, FreeBSD, Windows XP/Vista/7/8/10, Mac. • Sistemas operativos de computadoras de bolsillo. Se ejecutan sobre computadoras de tamaño reducido como pueden ser PDA (Personal Digit al Assistant), tabletas, teléfonos móviles o smartphones. Son similares a las computad oras personales, radicando las mayores diferencias en el peso, tamaño (y por tanto en la interfaz de usuario del sistema operativo) y en los recursos de los que disponen (c apacidad, velocidad de procesamiento, batería). Además, cada vez disponen de más sensores (giroscopio, posicionamiento, etc.). Ejemplos: Android, Windows Phone, iOS, Symbian. • Sistemas operativos integrados. También son conocid os como incrustados o embebidos (embedded), operan en los controladores de disposit ivos que no se consideran generalmente como computadores, ya que no aceptan s oftware instalado por el usuario. Esto significa la simplificación en la protección d e las aplicaciones. Estos dispositivos pueden ser microondas, televisores, automóviles, re productores DVD y MP3. Ejemplos: QNX, VxWorks, eCos. • Sistemas operativos de nodos de sensores. Cada nodo de esta red es una pequeña computadora que se comunica de forma inalámbrica co n una estación base. Tienen diversos usos como proteger perímetros de edificios , resguardar fronteras, detectar incendios o realizar mediciones ambientales (temper atura, humedad, etc.). Deben ser sistemas robustos para tolerar fallos en los nodos individuales y ser sencillo y simple dada la poca RAM disponible y la importancia de la durac ión de las baterías de los nodos. Ejemplos: TinyOS. • Sistemas operativos en tiempo real. Estos sistemas se caracterizan por tener el tiempo como parámetro clave. Se pueden clasificar en dos t ipos.
En tiempo real duro. La acción debe ocurrir sin exc epción en cierto momento o rango. Se suelen encontrar en procesos industriales, aeron áutica o milicia.
En tiempo real suave. Se acepta que muy ocasionalme nte se pueda fallar a un tiempo determinado. Los sistemas multimedia están en esta categoría. Ejemplos: QNX, RT-11, MarteOS, LynxOS. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Concepto, evolución y tendencias de los sistemas op erativos TEMARIO OPOSICIONES COIICV | TEMA 26 5 1.1.2. Estructura de un sistema operativo Como se ha visto, existe una gran variedad de siste mas operativos. Sin embargo, tienen muchas características comunes como se va a ver a continua ción. Los sistemas operativos modernos están controlados mediante interrupciones. Si no hay ningún proceso que ejecutar, ningún dispositivo de E/S al que dar servicio y ningún usuario al que responder, el sistema operativo debe permanecer esp erando a que algo ocurra. Esto reafirma la definición anteriormente dada de que un sistema ope rativo es aquel programa que se ejecuta continuamente en la computadora. Los sucesos casi siempre se indican mediante la ocu rrencia de una interrupción o una excepción. Una excepción es una interrupción generada por soft ware debida a un error o a una solicitud específica de un programa de usuario de que se real ice un servicio del sistema operativo. Es necesario asegurar que un error que se produzca en un programa de usuario sólo genere problemas en el programa que se esté ejecutando. Para gestionar esto y poder distinguir entre la eje cución del código del sistema operativo y el código definido por el usuario, el hardware suele p roporcionar como mínimo dos modos de ejecución: • Modo usuario (bit de modo = 1). • Modo kernel, también llamado modo de supervisor, mo do del sistema o modo privilegiado (bit de modo = 0). A esta manera de ejecutar código se le llama modo dual de operación . El sistema operativo arranca en modo kernel y los programas de usuario s e ejecutan en modo usuario. Si un programa de usuario solicita un servicio del sistema operati vo, se pasa a modo kernel para satisfacer la solicitud. Una vez finalizado el servicio, volverá a modo usuario. De este modo, las instrucciones que pueden causar daño (instrucciones privilegiadas ) sólo se ejecutan en modo kernel, lo que añade protección. Figura 2: Transición del modo usuario al modo kerne l Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019