Taller de Sistemas de Información 3. Presentación SCA

Transcripción

1 Taller de Sistemas de Información 3 Presentación SCA Integrantes: Gustavo Fava Diego Salido Marcos Techera agosto de 2008 TSI 3 1

2 Introducción a SCA Aplicación: conjunto de componentes de software trabajando en forma conjunta (punto de vista de SCA). Los componentes Pueden usar la misma tecnología, estar corriendo dentro del mismo proceso y estar corriendo en la misma maquina. O puede que no. Toda aplicación organizada necesita de Una manera de crear (implementar) los componentes y Una forma de describir como dichos componentes trabajan en conjunto. agosto de 2008 TSI 3 Presentación -.2

3 Definición Definición 1: SCA define una forma general de cómo crear componentes y de describir como interactúan estos entre si. Definición 2: Es un conjunto de especificaciones que describen un modelo para la construcción de aplicaciones SOA. Conclución La creación (implementación) de componentes que proveen servicios y que consumen otros servicios El ensamblaje o conjunción de dichos componentes para construir aplicaciones de negocio. agosto de 2008 TSI 3 Presentación -.3

4 Bases SCA Promueve el desacople de la implementación de los servicios y el ensamblado de los mismos, así de cómo son accedidas las funcionalidades de los mismos. Soporta implementaciones escritas en distintos lenguajes de programación y usando distintos estilos de programación. Por ejemplo Java, PHP, COBOL, C++, XSLT, SQL, etc. Ya sea con programación sincrónica o asincrónica. Soporte a distintas formas de comunicación para poder hacer uso de distintos servicios, Web Services, SCA, JCA, JMS, SLSB, etc. Promueve el uso de SDO (Service Data Objects) para poder representar la información del negocio. SDO es otra especificación para el intercambio de información. agosto de 2008 TSI 3 Presentación -.4

5 Especificación de SCA Esta dividida en una serie de documentos Cada documento maneja distintos aspectos de SCA, siendo los dos aspectos primordiales La implementación y el ensamblaje El modelo de ensamblaje es uno solo e independiente de la implementación La implementación, como ya se menciono, puede ser en distintos leguajes. En esta presentación nos basaremos en Java. agosto de 2008 TSI 3 Presentación -.5

6 Modelo de Ensamblado (The SCA Assembly Model) Serie de artefactos que definen la configuración de un sistema SCA en términos de: Componentes de servicios que implementan Componentes de servicios que usan De cómo interactúan entre si los distintos servicios. Los artefactos: SCA Composites y SCA Components Domains Services, References, Properties Bindings, Wires y Promote agosto de 2008 TSI 3 Presentación -.6

7 Artefactos agosto de 2008 TSI 3 Presentación -.7

8 Composite y Component Aplicación SCA: compuesta por uno o mas composites. Composite: combinación de components y/o composites. puede estar en una maquina o estar distribuido. Puede ser accedido por software no perteneciente al mundo SCA Puede acceder a software no perteneciente al mundo SCA Accede a datos como cualquier otra aplicación Component: noción generalizada totalmente independiente del lenguaje. agosto de 2008 TSI 3 Presentación -.8

9 Composite y Component (Cont.) SCDL (Service Component Definition Language) Lenguaje usado para especificar el ensamblado de los distintos artefactos. Archivo de configuración con extensión.composite Usa formato XML con la siguiente estructura: <composite name= ExampleComposite > <component name= Component1 > </component> <component name= Component2 > </component> <component name= Component3 > </component> </composite> agosto de 2008 TSI 3 Presentación -.9

10 Composite y Component (Cont.) agosto de 2008 TSI 3 Presentación -.10

11 Domains Engloba Components y composites Supuestos implicitos de los creadores de SCA En un entorno determinado se instala un grupo de productos SCA, comúnmente conocidos como runtimes, todos pertenecientes a un mismo proveedor Este grupo de runtimes es manejado por un mismo grupo de personas Definición: Grupo de sistemas que corren bajo el mismo runtime de un único vendedor y son manejados por el mismo grupo de personas. agosto de 2008 TSI 3 Presentación -.11

12 Domains agosto de 2008 TSI 3 Presentación -.12

13 Domains Importancia de los dominios SCA NO define completamente como componentes en diferentes maquinas deben de interactuar entre si (inter-process, intra-process e inter-machine) Cualquiera sea la elección de proveedor que se tome los composites no pueden estar formados por elementos pertenecientes a diferentes dominios. Comunicación con elementos fuera del dominio es através de mecanismos de interoperabilidad. NO esta definido ni para proveedores de runtimes SCA como comunicar componentes entre si, lo hace cada proveedor como quiere. agosto de 2008 TSI 3 Presentación -.13

14 Domains agosto de 2008 TSI 3 Presentación -.14

15 Components Components, Services, References, Properties y Bindigns Átomos a partir de los cuales se crean las aplicaciones SCA Se comportan de una forma esperada Pueden ser ensamblados de distintas maneras Entender los components es primordial para entender una aplicación SCA En SCA, un component es la instancia de una implementación que fue configurada apropiadamente. Se basan en una serie de abstracciones para definir las interacciones con el mundo exterior o Services, references, properties y bindings agosto de 2008 TSI 3 Presentación -.15

16 Components, Services, References, Properties y Bindigns (Cont.) agosto de 2008 TSI 3 Presentación -.16

17 Components Components, Services, References, Properties y Bindigns(Cont.) Implementan alguna lógica de negocio y la exponen como uno o mas servicios Así como expone servicios puede que use servicios de otros componentes (del dominio o fuera de este). Para indicar los servicios que usa un componente hace uso de las referencias. Además un component tiene propiedades, las cuales pueden ser leídas del archivo de configuración. Reference -> Service = Bindings. agosto de 2008 TSI 3 Presentación -.17

18 Bindings Referencias y Servicios permiten comunicar un componente con otro software Bindings: Especifican la tecnologia de comunicación de un service o un reference. Un service puede soportar mas de un binding. agosto de 2008 TSI 3 Presentación -.18

19 Bindings agosto de 2008 TSI 3 Presentación -.19

20 Wire y Promote Wire Representación abstracta de la relación entre una referencia y algún servicio que cumple con las necesidades de la referencia. La comunicación que proporciona un wire puede variar, depende del runtime usado, si esta o no especificado el binding, entre otras cosas. Promote Components exponen servicios Composites exponen uno o mas servicios, que en realidad son implementados por uno o mas components del composite. Para que estos servicios sean visibles como servicios del composite su creador debe de promover los servicios de los components Lo mismo ocurre con las referencias agosto de 2008 TSI 3 Presentación -.20

21 SCA Policy Framework Es una especificación que provee mecanismos para describir requerimientos no funcionales relacionados con los components, los composites y las conexiones entre ellos (representadas por servicios y referencias). El framework opera en 2 niveles: Alto nivel. Permite expresar en un lenguaje de alto nivel (abstracto) las características requeridas por un componente, servicio o referencia (ej. Protect messages from unauthorized reading or modification ). o Se las llama INTENTS Bajo nivel. Permite aplicar políticas concretas que satisfagan las de alto nivel. Se hace en tiempo de deploy. (ej. Encriptación usando RSA). o Se las llama POLICIES agosto de 2008 TSI 3 Presentación -.21

22 SCA Policy Framework Intents. Son afirmaciones abstractas sobre alguna característica que una construcción SCA deberá cumplir en tiempo de ejecución. Están expresadas en forma independiente de cualquier tecnología de implementación. Las define un Policy Administrator (rol). Las construcciones SCA se especifican como elementos xml, y las intents se adjuntan a esos elementos como atributos. También se pueden adjuntar a declaraciones de interfaces y clases por medio de anotaciones (Java). SCA provee un conjunto de intens básicas, que puede ser extendido por el adiministrador de policies. La definición de cada intent indica el elemento SCA al que aplica agosto de 2008 TSI 3 Presentación -.22

23 SCA Policy Framework Forma general: Ejemplo: agosto de 2008 TSI 3 Presentación -.23

24 SCA Policy Framework Policies. Al igual que las intents, se usan para describir alguna capacidad o restricción que se pueda aplicar a los componentes o a las interacciones entre componentes. Sin embargo las policies expresan la tecnología concreta que se debe usar. Cuando se hace el deploy las intents se traducen en policies. Por ejemplo, un servicio que requiere que sus mensajes sean autenticados puede ser marcado con una intent authentication. Esto indica que el servicio requiere autenticación de mensajes sin prescribir cómo debe realizarse. En tiempo de deploy, cuando se elije el binding para el servicio, por ejemplo SOAP sobre HTTP, el deployer puede aplicar al servicio policies adecuadas que provean aspectos de WS- Security (por ejemplo) y que provean un grupo de una o más tecnologías de autenticación. agosto de 2008 TSI 3 Presentación -.24

25 SCA Policy Framework Interaction Policies. Se aplican a servicios y referencias. Afectan la forma de la interacción en tiempo de ejecución. La forma en que son provistas dependen del tipo de binding. Implementation Policies. Se aplican a los componentes. Afectan la forma en que se comporta dentro de su entorno de ejecución. La forma en que son provistas dependen del runtime container. Algunas policies pueden ser provistas como parte inherente al tipo de runtime container o binding. Por ejemplo, un binding que utiliza https siempre proveerá encriptación para los mensajes. Asimismo, es posible que algunos tipos de containers y de bindings sean incapaces de proveer determinada policy. agosto de 2008 TSI 3 Presentación -.25

26 SCA Policy Framework PolicySets Las policies se mantienen en PolicySets. Pueden contener una o más policies. Cada PolicySet apunta a un tipo específico de binding o de tipo de implementación. Se usan para definir un conjunto concreto de policies que aplican a algún tipo de binding o tipo de implementación. Correponden a un conjunto de intents provistos por el policyset. IntentMaps. Forman parte de un policyset. Cotinenen las policies concretas y los policy subjects que son usados para realizar un intent. agosto de 2008 TSI 3 Presentación -.26

27 Ejemplo: agosto de 2008 TSI 3 Presentación -.27

28 SCA Policy Framework Archivo Definitions.xml Todas las Intents y policysets en un Dominio SCA se definen en un archivo global para todo el dominio llamado Definitions.xml Asociando Intents y PolicySets a elementos SCA. La asociación se indica por medio del atributo Su valor es una lista de nombres de Intents. Esto aplica a cualquier binding que se elija para el servicio. El deployer es libre de elegir cualquier policie que implemente confidentiality. agosto de 2008 TSI 3 Presentación -.28

29 Define Anotaciones o Marca servicios (interfaces) que podrán ser accedidos fuera del dominio. o Servicios (interfaces) para uso interno del dominio no necesitan ser o Define una referencia a un servicio dentro del mismo dominio. o Se aplica a un atributo cuyo tipo es una interfaz (servicio) o setter. o El runtime realiza injection del o Se aplica a un atributo (o un setter) cuyo tipo es un SDO o tipo simple. o Indica que el valor se debe obtener del SCDL. También tiene anotaciones para definir las Policy agosto de 2008 TSI 3 Presentación -.29

30 Runtimes Tuscany Runtime liviano para ser embebido fácilmente Soporta las especificaciones SCA y SDO Su diseño extensible permite integrar distintos tipos de servicios (BPEL, Springs, etc.) Puede ser hosteado en Apache Tomcat o Aplicaciones WEB pueden exponer y consumir servicios SCA Soporta WebServices para interoperar con otros servicios. Actualmente disponible versión 1.1 Fabric3 Permite crear y acceder servicios en distintas tecnologías (EJB, BPEL, etc.) Puede ser embebido en Servidores de Aplicación, aplicaciones J2SE, etc. Separa Controller (resolver wires, locación de servicios, etc.) de Nodos de Ejecucion (Runtime Nodes). Actualmente disponible versión 0.5 ALPHA 1 agosto de 2008 TSI 3 Presentación -.30

31 Runtimes (cont.) Newton Runtime distribuido Realiza wire y re-wire dinámico Detecta cambios en la topología de la red (si se mueven servicios) Actualmente disponible versión SCOrWare Ofrece Runtime y herramientas para diseño y desarrollo Herramientas integradas en eclipse The SOA for PHP Conjunto de tecnologías para dar soporte SCA en PHP No es un Runtime SCA The Mule Project Provee soporte SCA a Mule (ESB) agosto de 2008 TSI 3 Presentación -.31