Modelación y diseño de una arquitectura orientada a servicios para procesamiento penal en el MININT

Texto completo

(1)Universidad Central “Marta Abreu” de Las Villas.. Facultad Matemática, Física y Computación Licenciatura en Ciencia de la Computación. Modelación y diseño de una arquitectura orientada a servicios para procesamiento penal en el MININT.. AUTOR: Sandy Pérez Valdés TUTOR: Msc. Yoan Pacheco. “Año del 50 Aniversario del Triunfo de la Revolución”. Santa Clara 2009.

(2) “Detrás de cada logro hay otro desafío." Gastón Gaudio.. 2.

(3) Dedicatoria:. A mis padres que son los que lo han dado todo por mí. Aidé y Samuel 3.

(4) Agradecimientos:. A mi mamá que por su entrega y dedicación de tantos años, por ser mi guía y siempre confiar en mí. A mi papá que supo guiarme por buen camino. A mi hermano que quiero mucho. A mis cuatro abuelos y en especial a Mayo. A mis tíos Aimel y Yayo por brindarme su ayuda incondicional. A mi prima Lianet que gracias a su ayuda pude salir adelante en mis estudios. A mi novia Lisbety por ser tan especial y estar todos estos años al lado mío dándome apoyo y aliento. A mi tutor Yoan que me ayudó mucho en la realización de esta tesis. A todos mis amigos que estuvieron conmigo en las buenas y malas A todos los profesores que me formaron en el trascurso de mi carrera. Le agradezco a toda la gente linda y buena que ha estado junto a mí en toda mi vida.. 4.

(5) Hacemos constar que el presente Trabajo de Diploma ha sido realizado en la facultad de Matemática, Física y Computación de la Universidad Central “Marta Abreu” de Las Villas como parte de la culminación de los estudios de Licenciatura en Ciencia de la Computación, autorizando a que el mismo sea utilizado por la institución para los fines que estime conveniente, tanto de forma total como parcial y que además no podrá ser presentado en eventos ni publicado sin la previa autorización de la UCLV.. ______________________________. ______________________________. Firma del Autor. Firma del Autor. Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según acuerdo de la dirección de nuestro centro y que el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.. ________________________________. ________________________________. Firma del Tutor. Firma del Tutor. ________________________. Jefe del Seminario de…. 5.

(6) Resumen Se comenzó haciendo un estudio de las diferentes tecnologías de intercambio de datos entre aplicaciones distribuidas, desde Sockets, DCOM,etc. hasta otras más robustas, como los Servicios Web, y que se convirtieron en la base tecnológica de las arquitecturas orientadas a servicios. Tomamos como caso de estudio el procesamiento penal de los “Delitos de menor complejidad delictiva”, donde identificamos las actividades a automatizar, realizamos el análisis orientado a servicios y diseñamos las capas, las interfaces y las operaciones de los servicios. La arquitectura orientada a servicios propuesta promueve una solución ágil, duradera y adaptable al cambio.. 6.

(7) Abstract In our work we began a study of the various technologies for data exchange between distributed applications, until Sockets, DCOM, etc. to other more robust, such as Web services, which became the basis of service oriented architectures. We studied "criminal offenses of lower complexity” where we identify the activities to automate, also we do service-oriented analysis and design. Finally we define service interfaces and service operations. The proposed service-oriented architecture is flexible, durable and adaptable to change.. 7.

(8) Índice Resumen.............................................................................................................................. 6 Abstract ............................................................................................................................... 7 Índice................................................................................................................................... 8 Introducción ...................................................................................................................... 10 Capítulo I: Marco teórico.................................................................................................. 13 1.1. Evolución de los sistemas distribuidos:................................................................. 13 1.2. Arquiteturas Orientadas a Servicios (SOA): .......................................................... 23 1.2.1 Historia y surgimiento de SOA: ....................................................................... 24 1.2.2 Principios de la orientación a servicios: ........................................................... 26 1.2.3 Capas de servicios: ........................................................................................... 28 1.2.4 Diferencias con otras arquitecturas................................................................... 32 1.2.5 Concepciones erróneas de SOA: ...................................................................... 33 1.2.6 Beneficios de SOA: .......................................................................................... 33 1.2.7 Problemas comunes de la adopción de SOA:................................................... 34 1.3. Estrategias de desarrollo:........................................................................................ 34 1.4.SOA y el modelado de procesos de negocio (BPM) ............................................... 42 Conclusiones parciales: ................................................................................................. 43 Capítulo II: Análisis orientado a servicios del sistema de procesamiento penal. ............. 44 2.1. Análisis Orientado a servicios: ............................................................................... 44 Conclusiones parciales...................................................................................................... 61 Capítulo III: Diseño orientado a servicios: ....................................................................... 62 3.1 Introducción al diseño de servicios. ........................................................................ 62 3.2 Prerrequisitos a tener en cuenta en esta fase............................................................ 63 3.2.1WSDL relacionado con Schema Definition Language (XSD) .......................... 63 3.2.2Conceptos básicos del lenguaje WSDL............................................................. 64 3.2.3Protocolos de comunicación SOAP................................................................... 67 3.3 Diseño de servicios de negocio centrados en entidades .......................................... 68 3.4 Diseño de servicios de aplicación............................................................................ 88 8.

(9) 3.5 Diseño de servicios de negocio centrados en tareas ................................................ 93 Conclusiones parciales ................................................................................................ 100 Conclusiones ................................................................................................................... 101 Recomendaciones ........................................................................................................... 102 Bibliografía ..................................................................................................................... 103. 9.

(10) Introducción El tipo de sociedad que el nuevo orden mundial ofrece, el desarrollo de las tecnologías de la información y la comunicación, las tendencias de negocios a través de medios electrónicos, las nuevas teorías organizacionales y el modus operandi del ser humano en el siglo XXI requiere la automatización de los procesos cotidianos y la despersonalización en muchos de ellos. Estos argumentos han sido algunos de los pilares que han hecho surgir nuevos desarrollos tecnológicos y entre ellos los que a software se refiere, creando una nueva perspectiva sobre el desarrollo de software imponiendo nuevas arquitecturas entre las que se desatacan las arquitecturas web. Sobre estas últimas, se han empezado a aprovechar estándares y protocolos que facilitan la interoperabilidad de las aplicaciones sobre la red y especialmente sobre internet naciendo así el concepto de servicio web. En las arquitecturas de TI(tecnologías de información ) tradicionales, las actividades del proceso de negocios, las aplicaciones y los datos con frecuencia están encerrados en "silos" independientes e incompatibles que son caros de mantener y dejan a los usuarios la necesidad de navegar entre redes, aplicaciones y bases de datos independientes para realizar tareas de negocios concretas. Con una Arquitectura Orientada a Servicios (SOA), los usuarios ya no tienen que iniciar sesión en varios sistemas, buscar los datos relevantes e integrar los resultados manualmente. Los datos de las actividades de los procesos de negocios se entregan como un servicio integrado, en una sola aplicación, en una sola pantalla, con un solo inicio de sesión. SOA y la modelación de procesos de negocio (BPM), son complementarios y permiten optimizar las aportaciones de cada uno gracias a sus propias virtudes. En efecto, SOA es una aproximación dirigida por las TI mientras que el BPM se orienta hacia el negocio, la unión de estas dos herramientas permite entonces una mejor adecuación entre los objetivos de los servicios informáticos y los objetivos de negocio. Además, la. 10.

(11) comunicación entre los dos está entonces asegurada con el objetivo común de mejorar el rendimiento. Una aproximación SOA, que facilita la interacción de las aplicaciones informáticas de una empresa para optimizar su uso, puede muy bien apoyarse inicialmente en una perspectiva de modelización de los procesos: es necesario identificar qué procesos se desean ejecutar y en qué formato para así tener en cuenta el tipo de aplicaciones requeridas. La implementación de una arquitectura orientada a servicios será eficaz desde el momento en que deriva de un objetivo de negocio; por lo tanto, de un proceso. Inversamente, la implementación de soluciones de BPM requiere también por definición de la gestión de procesos. Su objetivo es racionalizar la utilización de las aplicaciones para la realización de un proceso de negocio. Una arquitectura SOA permitirá una implementación más sencilla y rápida de las aplicaciones de BPM para obtener así mejores resultados. SOA representa los procesos de negocio como servicios. El BPM tendrá que integrar esta noción orientando sus aplicaciones para asegurar una comunicación óptima y una mejor flexibilidad. El problema fundamental que se aborda en este trabajo es el uso de una metodología de diseño centrada en el desarrollo de procesos de negocios y orientada a servicios en la automatización del procesamiento penal en el ministerio del interior. El objetivo general de esta tesis es: Analizar y diseñar una arquitectura orientada a servicios para el “ procesamiento penal” realizado por el ministerio del Interior de Villa Clara, específicamente del subproceso relacionado con los delitos de la “menor complejidad delictiva”. Y como objetivos específicos: . Realizar el estudio de la actividad relacionada con el “Procesamiento penal” para determinar las distintos procesos y tareas que deben ser implementados mediante una arquitectura SOA.. . Modelar las capas y los servicios candidatos que respondan a la lógica del proceso de negocio.. 11.

(12) . Diseñar las interfaces de los servicios de la arquitectura SOA propuesta.. La estructura en Capítulos es la siguiente: Capítulo1: Marco teórico En este capítulo se ve como evolucionaron lo distintos sistemas distribuidos, haciendo hincapié en la tecnología servicios web, que son el pilar fundamental en las arquitecturas orientadas a servicios. Capítulo2: Análisis orientado a servicios de el sistema de procesamiento penal. En este capítulo se realiza un análisis orientado a servicios de la actividad relacionada con el procesamiento penal realizada por el MININT, centrándonos en el subproceso “Delitos de menor complejidad” donde nos apoyamos en una modelación de procesos de negocio, la cual nos sirve de base para conformar una propuesta inicial de los servicios candidatos y sus composiciones. Capítulo3: Diseño orientado a servicios del subproceso relacionado con los delitos de la menor complejidad delictiva. En este capítulo se realiza el diseño concreto de servicios físicos derivándolos de la lógica de servicios candidatos y el ensamblaje dentro de composiciones abstractas que ponen en marcha el proceso de negocio. Se realiza un diseño donde se obtiene la descripción de todos los servicios candidatos utilizando la herramienta XMLSpy para conformar dichas interfaces.. 12.

(13) Capítulo I: Marco teórico 1.1. Evolución de los sistemas distribuidos: A continuación se realiza un estudio de las tecnologías de intercambio de datos entre aplicaciones distribuidas, con esto se pretende comprender la evolución de los sistemas distribuidos a lo largo del tiempo, sus ventajas y deficiencias hasta llegar al estado actual donde se analizan los servicios Webs que son la base tecnológica de las arquitecturas orientadas a servicios. 1.1.1 Sockets: Una de las primeras soluciones a la implementación de sistemas distribuidos para el intercambio de datos fueron los sockets, que precisamente tienen la capacidad de comunicar dos procesos, ya sea mediante datagramas o flujos de datos (streams). Sin embargo, los sockets requieren que las aplicaciones implementen sus propios protocolos para codificar y decodificar los mensajes que intercambian, lo que introduce una problemática diferente a la naturaleza del problema a resolver y aumenta la posibilidad de errores durante la ejecución, es por ello que los sockets son una solución base, utilizada por tecnologías más modernas para la implementación de sistemas distribuidos complejos. 1.1.2 Remote Procedure Call (RPC): Una de las primeras alternativas que surgió al empleo de los sockets fue RPC la cual es una abreviatura para Remote Procedure Call y una especificación diseñada por el Open Group (Group, Group). RPC es el pilar arquitectónico de muchas de las tecnologías de acceso remoto. La cual incluye: . Proxies y stubs: Código presente en clientes y servidores cuyo propósito es hacer y recibir llamadas remotas como si fueran locales.. . Marshaling de datos: El proceso de empaquetar una cadena de datos que contiene el nombre de una llamada y sus parámetros.. 13.

(14) . Lenguaje de definición de interfaz (IDL): Un tipo de documento que lista el nombre y los parámetros de los procedimientos que los clientes remotos pueden invocar.. En la figura 1.1 se muestra una estructura RPC típica .Para invocar una función remota, el cliente hace llamadas al proxy del cliente. El proxy empaqueta los parámetros de la llamada en un mensaje de solicitud e invoca el protocolo de transporte para que lleve el mensaje al servidor. En el lado del servidor, el protocolo de transporte entrega el mensaje al stub del servidor, este entonces desempaca el mensaje de solicitud y llama la función correcta en el objeto.. Figura 1.1. Arquitectura RPC Básica 1.1.3 Distributed COM (DCOM) DCOM es la extensión distribuida del COM de Microsoft (Component Object Model)(Corporation) la cual construye una capa de llamadas procedurales a objetos remotos (ORPC) sobre DCE RPC(Group) para soportar objetos remotos, donde. la. interacción entre los procesos cliente y servidor de objetos son implementados como comunicaciones, estilo RPC, orientadas a objeto (Nelson, 1984).Soporta múltiples(Parra., 2006, Mayo, 21 21 #1). interfaces, cada una representando una vista o comportamiento diferente. del objeto. Como la especificación es a nivel binario, permite la integración de componentes binarios escritos en diferentes lenguajes de programación como C++, Java, y Visual Basic. 14.

(15) DCOM es propietaria de Microsoft y no se ha implementado sobre otros sistemas operativos, lo cual limita la extensibilidad de una solución basada en esta tecnología. 1.1.4 Common Object Request Broker Architecture (CORBA) CORBA es una plataforma de objetos distribuidos propuesta por un consorcio de más de 700 compañías, llamado Object Management Group (OMG)(July 1995). Su objetivo fue definir una arquitectura que permitiera la comunicación entre ambientes heterogéneos a nivel de objeto, sin importar quien diseñase los puntos finales de la aplicación distribuida. Consta de un Lenguaje de Definición de Interfaz (IDL) y un API que posibilita la interacción entre el cliente y el servidor a nivel de objeto dentro de una implementación específica de un Object Request Broker (ORB). Su objetivo fue definir una arquitectura que permitiera la comunicación entre ambientes heterogéneos permitiendo que aplicaciones en varios sistemas operativos puedan comunicarse. 1.1.5 DCOM y CORBA en el diseño de sistemas distribuidos. En ambos, la interacción entre los procesos cliente y servidor de objetos son implementados como comunicaciones, estilo RPC. Los dos protocolos son razonables para comunicaciones en el ambiente para el cual fueron diseñados. Por ejemplo, si todas las aplicaciones que quieren comunicarse están en la misma una intranet sobre Windows entonces tendría sentido usar DCOM para lograr la interoperabilidad entre ellas. O si se quiere lograr interoperabilidad entre aplicaciones sobre diferentes sistemas operativos en una intranet podría usarse CORBA. Sin embargo, cuando las máquinas clientes están distribuidas a través de Internet la comunicación debería hacerse usando otro estándar pues el paso de mensajes a través de firewalls usando estas tecnologías muchas veces limita la efectividad del firewall, lo cual no es deseable pues se comprometería la seguridad de todo el sistema. Debería utilizarse otro estándar más seguro y escalable. 1.1.6 Java Remote Method Invocation (Java RMI): Java Remote Method Invocation (Java RMI(Sun Microsystems, 2003)) es la versión orientada a objetos de Remote Procedure Calls (RPC). Mientras RPC permite llamar procedimientos a través de la red, Java RMI invoca un método de un objeto a través de la red. 15.

(16) 1.1.6.1 Definición de interfaz: El lenguaje Java permite la definición de interfaces, las cuales aíslan al programador de los detalles de la implementación y establecen un contrato entre la clase que implementa la interfaz y el objeto que invoca los métodos de la misma. RMI hace uso de las interfaces para declarar las funciones que exporta un objeto remoto. 1.1.6.2 Arquitectura de Java RMI: Como podemos ver en la fig1.2 RMI utiliza el mismo mecanismo que los sistemas RPC para implementar la comunicación con los objetos remotos, el basado en stubs y skeletons.. Figura 1.2 Arquitectura de Java RMI. 1.1.6.4 Utilización de RMI a través de firewalls por medio de Proxies: Para atravesar el firewall, la capa de transporte de RMI incluye la llamada remota dentro del protocolo HTTP, como el cuerpo de una solicitud POST, mientras que los valores de retorno se reciben en el cuerpo de la respuesta HTTP. La capa de transporte de RMI puede formular la solicitud POST, de alguna de las dos maneras siguientes: 1. Si el firewall permite entregar una solicitud HTTP directamente sobre cualquier puerto de la máquina destino, la solicitud se dirige directamente al puerto donde el servidor RMI se encuentra escuchando. La capa de transporte RMI en la máquina destino escucha con 16.

(17) un socket que es capaz de entender y decodificar llamadas RMI, que se encuentren dentro de una solicitud POST. 2. Si el firewall sólo entrega solicitudes HTTP a ciertos puertos HTTP bien conocidos, la llamada se envía a un servidor HTTP que se encuentre escuchando en el puerto 80, donde se puede ejecutar un guión (script) CGI que se encargue de enviar la llamada RMI al puerto específico del servidor. 1.1.6.5 RMI en el diseño de sistemas distribuidos: La invocación remota de métodos en Java parte del hecho de correr sobre una plataforma homogénea, por tanto RMI forma parte de todo Java Developer Kit (JDK), por ende, cualquier plataforma que tenga acceso a un JDK también tendrá acceso a estos procedimientos. RMI está diseñada para tomar ventaja de esta característica, lo que le permite presentar propiedades que otros modelos de objetos como CORBA no poseen. RMI posee todas las características de seguridad que hereda de la plataforma Java misma como la recolección de basura distribuida y el manejo de hilos. Brinda soluciones para traspasar firewalls sin comprometer la efectividad de los mismos. Pero a diferencia de CORBA, que posee una arquitectura que proporciona independencia del lenguaje de programación, RMI está diseñada exclusivamente para Java lo cual hace más recomendable su uso cuando los sistemas que se quieren implementar están basados en tecnología Java. 1.1.7 .Net Remoting: Con el advenimiento de la plataforma .NET, Microsoft introdujo un conjunto de nuevas tecnologías, .NET remoting (Hawkins, July 2001) es una de ellas, la cual provee un sistema genérico que usan diferentes aplicaciones para comunicarse entre ellas. Los objetos .NET son expuestos a procesos remotos, permitiendo por tanto la comunicación interprocesos. Las aplicaciones pueden estar localizadas en la misma computadora, en diferentes computadoras, en la misma red o incluso en diferentes computadoras en diferentes redes.. 17.

(18) .NET Remoting utiliza una arquitectura flexible y extensible y usa el concepto de .NET llamado Dominio de Aplicación (AppDomain) para determinar su actividad La infraestructura de .Net Remoting permite crear dos tipos distintos de objetos: 1. Objetos activados por el cliente 2. Objetos activados por el servidor. 1.1.7.1 Arquitectura de .Net Remoting: La plataforma Remoting viene con dos formateadores: un formateador binario y un formateador SOAP (fig1.3). El formateador binario es muy rápido, y codifica las llamadas a los métodos en un formato binario propietario. El formateador SOAP es más lento, pero permite a los desarrolladores codificar los mensajes remotos en formato SOAP.. Figura 1.3. Arquitetura de .Net Remoting. 1.1.7.2 Utilización de .Net Remoting a través de firewalls por medio de Proxies: .Net Remoting evolucionó de tecnologías como DCOM basadas en un protocolo binario que limita la interoperabilidad entre plataformas. Con .NET Remoting se eliminan estas dificultades pues soporta diferentes formatos para los protocolo de transporte y comunicaciones usando el formateador SOAP y el canal de comunicaciones HttpChannel. 18.

(19) se puede lograr la comunicación entre aplicaciones detrás de firewalls y sobre diferentes sistemas operativos. 1.1.7.3 .Net Remoting en el diseño de aplicaciones distribuidas: .Net Remoting es una fuerte tecnología que provee una cómoda plataforma para el desarrollo de aplicaciones distribuidas. Para las aplicaciones que requieran comunicación con otros componentes de la plataforma .NET probablemente esta sea la mejor opción pues se puede integrar con los servidores y otros servicios de la misma. .NET Remoting garantiza la interoperabilidad con otras soluciones a través del uso de formateador SOAP y el canal de comunicación HTTP lo cual le permite atravesar firewalls. Sin embargo existen otras tecnologías, como los servicios Web que son más adecuados para lograr interoperabilidad entre diferentes estándares. Podrían combinarse ambas soluciones utilizando .NET Remoting para la comunicación con clientes .NET de una intranet y servicios Web para la comunicación con clientes externos en otras plataformas y así tomar ventajas de lo mejor de ambas propuestas (fig1.4).. Figura 1.4. Combinación de .Net Remoting y servicios Web.. 19.

(20) 1.1.8 XML-RPC: XML-RPC es una especificación y un conjunto de implementaciones que permiten que software corra en diversos sistemas operativos y ambientes, hacer llamadas a procedimientos a través de Internet. Esto es llamadas a procedimientos remotos (RPC) usando HTTP como transporte y XML como codificador. XML-RPC fue diseñado para ser tan simple como sea posible, y que a su vez permita que estructuras de datos complejas sean transmitidas, procesadas y retornadas (Kidd's, July 3, 2003).. Figura 1.5. Arquitectura XML-RPC 1.1.8.1 Objetivos específicos de XML-RPC: Paso a través de firewalls: El objetivo de este protocolo es establecer una plataforma compatible a través de diferentes ambientes, de modo que el software del firewall espere mensajes POST cuyo contenido sea texto o XML. Fácil Comprensión: Plantear un formato extensible que es muy simple. Debe ser posible para un programador Web, de modo fácil, revisar un archivo conteniendo una llamada XML-RPC, entender que es lo que hace, y ser capaz de modificarlo y ponerlo a punto en el primer intento.. 20.

(21) Fácil implementación: Se pensó en un protocolo fácil de implementar que pudiera ser rápidamente adaptado para que corra en otro ambiente o sistema operativo. 1.1.8.2 XML-RPC en el diseño de aplicaciones distribuidas: XML-RPC presenta un número de limitaciones que hay que tener en cuenta a la hora de diseñar sistemas distribuidos complejos, como por ejemplo: •. Llamadas a métodos. •. Nombramiento de estructuras de datos:. •. Simplicidad:. En resumen XML-RPC es una tecnología simple, fácil de entender, basada en peticiones y respuestas, que posibilita la interoperabilidad entre aplicaciones corriendo sobre diferentes sistemas operativos y a través de firewalls. Si lo que se requiere es la posibilidad de enviar tipos de datos complejos definidos por el usuario y la habilidad de que cada mensaje defina como debe ser procesado entonces SOAP es una mejor solución que XML-RPC. Pero si tipos de datos estándar y llamadas a métodos simples es lo que se necesita entonces XML-RPC le dará al desarrollador aplicaciones más rápidas con menos trabajo. 1.1.9 Servicios Web Recientemente, los Servicios Web han estado emergiendo como una plataforma sistemática y extensible para interacciones entre aplicaciones, construida sobre protocolos Web existentes y estándares XML abiertos (2002). Los servicios Web son un nuevo tipo de aplicación Web. Son aplicaciones modulares auto contenidas y auto descritas, que pueden ser publicadas, localizadas e invocadas a través de la Web. Pueden realizar funciones sencillas como simples llamadas solicitando información o crear y ejecutar complejos procesos de negocio. Una vez que el servicio Web se ha desplegado, este puede ser descubierto e invocado por otras aplicaciones (u otros servicios Web). La ventaja clave de los servicios Web es la habilidad de crear aplicaciones al vuelo a través del uso de componentes de software reusables y débilmente acoplados. Esto tiene implicaciones importantes en las tecnologías y aplicaciones de negocios. El software 21.

(22) puede ser entregado y pagado como una cadena de servicios a diferencia de la manera tradicional, productos empaquetados. La plataforma de los servicios Web está dividida en tres áreas fig1.6: 1. Protocolos de comunicación (SOAP): Simple Object Access Protocol (SOAP) posibilita la comunicación entre servicios Web y es fundamentalmente un paradigma sin estados, para el intercambio de mensajes en un solo sentido que posibilita a las aplicaciones la creación de patrones de interacción más complejos, que pueden ser transportados sobre HTTP. EL protocolo HTTP donde hace el papel de puente en las interacciones entre sistemas de computadoras. 2. Descripción del servicio (WSDL): El lenguaje de descripción de servicios Web (WSDL (Christensen, 15 march 2001)) brinda un lenguaje entendible por las computadoras para la descripción de los servicios Web mediante un modelo y un formato XML. 3. Descubrimiento del servicio (UDDI): Universal Description Discovery & Integration (UDDI) brinda un mecanismo para. que. los clientes encuentren los servicios Web enfocándose en la definición de un conjunto de servicios que dan soporte a la descripción y descubrimiento de negocios, organizaciones y otros proveedores de servicios Web.. Figura 1.6. Descubrimiento e invocación de servicios Web. 1.1.9.1 Los servicios Web en el diseño de aplicaciones distribuidas: 22.

(23) Los servicios Web fueron diseñados para atacar el problema de la integración de fuentes heterogéneas y hacer interoperar sistemas heterogéneos. Tecnologías como CORBA y RPC tenían los mismos objetivos, pero cada una con su propia infraestructura. Por tanto, las soluciones al problema de la integración de sistemas heterogéneos eran muy caras. Los servicios Web son una buena opción para arquitecturas débilmente acopladas (Christoph Bussler, 2003).La arquitectura CORBA es mas adecuada para ambientes intraempresariales, mientras que las características técnicas de los servicios Web los hacen más reusables y por tanto más apropiados para ambientes globales e inter-empresariales. En la adopción de esta tecnología hay que tener en cuenta que si no se realiza un diseño correcto de los servicios Web y sus relaciones con otros servicios Web internos o externos pueden dejar de ser útiles para sus clientes al cambiar el proceso de negocio o las necesidades de los clientes, a esta problemática se le da respuesta en el área de la Arquitecturas Orientadas a Servicios (SOA).. 1.2. Arquiteturas Orientadas a Servicios (SOA): Después de hacer un breve recorrido por la evolución de los sistemas distribuidos, nos centraremos en. estudiar y profundizar aspectos relacionados con las Arquitecturas. Orientadas Servicios (SOA) las que pueden ser implementadas con servicios web estos aspectos nos permitirán una mejor comprensión del proceso de diseño de una arquitectura S.O.A. para el proceso de negocio “Gestión del procesamiento penal” realizado por el ministerio del Interior de Villa Clara. La computación está entrando en una nueva era marcada fundamentalmente por el desarrollo de Internet, las aplicaciones móviles, la programación distribuida y los servicios Web. Ya hoy en día se cuenta con tecnologías sólidas que hacen que se puedan desarrollar aplicaciones que puedan ser consumidas por una gran variedad de dispositivos, sistemas operativos sin importar la ubicación geográfica. En esta nueva era de la computación también aparece un nuevo concepto de arquitectura para enfrentar los más diversos problemas: Las arquitecturas orientadas a servicios (Burneo, July 2002). Una Arquitectura Orientada a Servicios es un paradigma para organizar y utilizar capacidades distribuidas bajo el control de diferentes dominios siendo capaz de de manejar una serie de características. 23.

(24) • • • • • • •. Independencia de la plataforma Estar basado en estándares Reuso Granularidad Modularidad Posibilidad de división en componentes Composición de los servicios. Estas características se logran aplicando una serie de principios de diseño, los cuales garantizan las mismas.. 1.2.1 Historia y surgimiento de SOA: SOA no es un concepto nuevo. Los ingenieros software entendieron sus principios a mediados de los 80 cuando llegaron al mercado la computación distribuida y las llamadas a procedimientos remotos. En 2003, SOA entra al fin por completo en el mundo de las TI empresariales, a través de los servicios web. Desde el punto de vista de las arquitecturas de software, el término servicio ha sido utilizado, tradicionalmente, para describir una función de negocio auto contenida, con una interfaz bien definida y estable, que recibe requerimientos de sus clientes. El servicio no depende del contexto de sus clientes y puede ser consumido por varios sistemas sin ser modificado. Los servicios son instalados (o desplegados) una única vez (esto los diferencia de los componentes que deben ser incluidos dentro del contexto de cada aplicación que requiera de su uso) y permanecen disponibles, sin consumir recursos, hasta que son invocados. Una. vez. aclarada. la. definición. de. servicio,. podemos. avanzar. sobre. la de SOA. Estamos hablando de un estilo arquitectónico que va más allá de la implementación, al definir principios de diseño, patrones y criterios que permiten lograr características tales como modularidad, encapsulamiento, bajo acoplamiento, reuso composición, separación de responsabilidades ,etc.. Finalmente, para un desarrollador, SOA es un modelo de programación que provee de estándares, herramientas y tecnologías concretas, que le permiten llevar a cabo su tarea diaria. Inicialmente SOA se modelaba con 3 componentes: WSDL, SOAP, UDDI como podemos apreciar en la Fig.1.7 24.

(25) Fig.1.7 SOA Inicial. Mas adelante las empresas crearon asociaciones que desarrollaron especificaciones conocidas como WS-*: (Segunda generación SOA) Con el ánimo de extender las capacidades de los servicios web, algunas de ellas son: WS-Adressing: de donde viene el mensaje, hacia donde va. WS-ReliableMessaging: llegó o no el mensaje, llegaron en orden WS-Policy: Permite manejar restricciones del negocio. WS-Security: Maneja Identificación, autentificación, y autorización. Aunque los servicios web no necesariamente significan SOA, y no todas las SOAs están basadas en servicios web, la relación entre las dos tendencias es importante, y se potencian mutuamente: el interés por los servicios web lleva hacia SOA, y las ventajas de la arquitectura SOA ayudan a que las iniciativas de servicios web tengan éxito. 25.

(26) 1.2.2 Principios de la orientación a servicios: Para que una aplicación sea verdaderamente SOA tiene que cumplir con los Principios de la Orientación a Servicios. No existe una definición estándar de cuales son los Principios de la Orientación a Servicios, por lo tanto, lo único que se puede proporcionar es un conjunto de principios que estén muy asociados con la Orientación a Servicios. Estos Principios según Thomas Erl(Erl, 2005) son: 1. Acople bajo: Es decir, que los servicios tienen que ser independientes los unos de los otros. Para lograr ese bajo acoplamiento, lo que se hará es que cada vez que se vaya a ejecutar un servicio, se accederá a él a través del contrato, logrando así la independencia entre el servicio que se va a ejecutar y el que lo llama. Si conseguimos este bajo acoplamiento, entonces los servicios podrán ser totalmente reutilizables. 2. Contratos de servicios: Todo servicio desarrollado, debe proporcionar un contrato en el cual figuren: el nombre del servicio, su forma de acceso, las funcionales que ofrece, los datos de entrada de cada una de las funcionalidades y los datos de salida. De esta manera, todo consumidor del servicio, accederá a este mediante el contrato, logrando así la independencia entre el consumidor y la implementación del propio servicio. En el caso de los Servicios Web, esto se logrará mediante la definición de interfaces con WSDL. 3. Autonomía: Todo Servicio debe tener su propio entorno de ejecución. De esta manera el servicio es totalmente independiente y nos podemos asegurar que así podrá ser reutilizable desde el punto de vista de la plataforma de ejecución. 4. Reuso: Todo servicio debe ser diseñado y construido pensando en su reutilización dentro de la misma aplicación, dentro del dominio de aplicaciones de la empresa o incluso dentro del dominio público para su uso masivo. 5. Composición: Todo servicio debe ser construido de tal manera que pueda ser utilizado para construir servicios genéricos de más alto nivel, el cual estará compuesto de servicios de más bajo nivel. En el caso de los Servicios Web, esto. 26.

(27) se logrará mediante el uso de los protocolos para orquestación (WS-BPEL) y coreografía (WS-CDL). 6. Ausencia de estado: Un servicio no debe guardar ningún tipo de información. Esto es así porque una aplicación está formada por un conjunto de servicios, lo que implica que si un servicio almacena algún tipo de información, se pueden producir problemas de inconsistencia de datos. La solución, es que un servicio sólo contenga lógica, y que toda información esté almacenada en algún sistema de información sea del tipo que sea. 7. Descubrimiento: Todo servicio debe poder ser descubierto de alguna forma para que pueda ser utilizado, consiguiendo así evitar la creación accidental de servicios que proporcionen las mismas funcionalidades. En el caso de los Servicios Web, el descubrimiento se logrará publicando los interfaces de los servicios en registros UDDI. Cuando se desarrollan aplicaciones SOA es muy útil y necesario tener en cuenta siempre estos principios, ya que nos van a dar las pautas necesarias para tomar ciertas decisiones de diseño. Como se habrá podido observar, una característica muy importante de los Principios de la Orientación a Servicios, es que todos ellos se inter-relacionan Fig1.8.. 27.

(28) Fig. 1.8 Relación entre los principios de la orientación a servicios. Como se puede observar en la Fig. 1.8, el objetivo de la Orientación a Servicios es obtener software totalmente reutilizable a través de un conjunto de técnicas y principios como los descritos anteriormente.. 1.2.3 Capas de servicios: En el modelo empresarial que comúnmente analizamos la capa de interfaz de servicios se localiza entre el proceso de negocio las capas de la aplicación, siendo por consiguiente el área de nuestra empresa en donde las características de SOA son más notables. Entonces cabe hacerse las siguientes preguntas: 1. ¿Qué lógica debe representarse por los servicios? 2. ¿Cómo los servicios se relacionan a la lógica de aplicaciones existentes? 3. ¿Cómo los servicios pueden representar mejor la lógica del proceso del negocio? 4. ¿Cómo los servicios pueden construirse y posicionarse para brindar la agilidad requerida?. 28.

(29) ¿Qué lógica debe representarse por los servicios? La lógica del negocio puede ser dividida en dos dominios primarios: la lógica del negocio y lógica de la aplicación. Pueden planearse los servicios para representar cualquiera o ambos tipos de lógica, con tal de que puedan aplicarse los principios de orientación a servicios. Cuando las colecciones individuales de servicios representan lógica de negocio corporativa y la lógica de la aplicación de una tecnología específica, cada dominio de la empresa se libra de dependencias directas. Esto establece una relación débilmente acoplada entre el negocio y lógica de la aplicación. ¿Cómo los servicios deben relacionar a la lógica de la aplicación existente? Los sistemas existentes pueden imponer cualquier número de. restricciones o. limitaciones, y los requisitos que necesitan ser tenidos en cuenta durante el descubrimiento de los servicios. Los servicios diseñados específicamente para representar la lógica de la aplicación deben existir en una capa aparte. ¿Cómo los servicios pueden representar mejor la lógica del proceso de negocio? La lógica del proceso de negocio se define dentro de los modelos de negocio de una organización. Cuando los servicios modelados representen la lógica del negocio, es muy importante asegurar que la representación de servicio de esta lógica esté alineada con los modelos de negocio existentes. ¿Cómo los servicios pueden construirse y pueden posicionarse para promover la agilidad requerida? La orquestación se diseña específicamente para este propósito. Introduce el concepto de un servicio del proceso, capaz de componer otros servicios para completar un proceso de negocio según la lógica del flujo de trabajo definida previamente. Los servicios del proceso establecen la capa de servicios de orquestación. Un elemento común a todas estas respuestas son las capas de abstracción que marcan unas de las principales características de SOA (Fig. 1.9).. 29.

(30) Las tres capas primarias de abstracción que se identifican para SOA son:. 1. La capa de servicio de aplicación: La capa de servicio de aplicación establece los diferentes niveles que existen para expresar el funcionamiento de una tecnología específica. Los servicios que residen dentro de esta capa simplemente pueden ser referidos como los servicios de aplicación. Su propósito es proporcionar funciones reusables relacionadas con el procesamiento de los datos dentro de nuevo o ambientes de aplicación. Los servicios de aplicación normalmente tienen las características siguientes: . Exponen las funcionalidades dentro de un contexto del proceso específico.. . Utilizan los recursos disponibles dentro de una plataforma dada.. . Son solución-agnósticos.. . Son genéricos y reusables.. . Pueden usarse para lograr la integración del punto a punto con otros servicios de la aplicación.. . Pueden consistir en una mezcla de servicios desarrollados dentro de la empresa y servicios de terceros que se han comprado o se han arrendado.. 2. La capa de servicios de negocio: Mientras los servicios de la aplicación son los responsables de representar tecnología y lógica de una aplicación, la capa de servicios de negocio introduce un servicio que se interesa solamente con representar la lógica de negocio, nombrado servicio de negocio. La abstracción de capa de servicio de negocio incluye la creación de dos modelos de servicio de negocio adicionales: 1. Servicio de negocios centrado en tareas: Es un servicio que encapsula la lógica de negocio específica a una tarea o el proceso de negocio. Este tipo de servicio generalmente se requiere cuando la lógica del proceso de negocio no se centraliza como la parte de una capa de orquestación. Los servicios de negocio centrados en tareas limitan el reuso.. 30.

(31) 2. Servicio de negocios centrado en entidades: Es un servicio que encapsula una entidad de negocio específica (como una factura). Los servicios centrados en entidades son útiles para crear servicios agnósticos, altamente reusables. 3. La capa de servicios de orquestación: La capa de servicios de orquestación es la de mayor nivel de abstracción y se encarga de manejar los detalles de la interacción entre los demás servicios exigiendo y garantizando que el funcionamiento se ejecute en una sucesión específica. Dentro de la capa de servicios de orquestación, los servicios del proceso componen otros servicios que proporcionan juegos específicos de funciones, independientes de las reglas de negocio. La orquestación es más valiosa para nosotros que un proceso de negocio normal, ya que nos permite enlazar la lógica del proceso a las interacciones de servicios dentro de la lógica del flujo de trabajo. Lo anterior combina la modelación del proceso de negocio con el diseño y modelación de arquitecturas orientadas a servicios (SOA).. 31.

(32) Fig.1.9 Capas de servicio primarias. 1.2.4 Diferencias con otras arquitecturas Al contrario de las arquitecturas orientado a objetos, las SOAs están formadas por servicios de aplicación débilmente acoplados y altamente interoperables. Para comunicarse entre sí, estos servicios se basan en una definición formal independiente de la plataforma subyacente y del lenguaje de programación, como los WSDL (Lenguaje de Descripción de Servicios Web). La definición de la interfaz encapsula (oculta) las particularidades de una implementación, lo que la hace independiente del fabricante, del lenguaje de programación o de la tecnología de desarrollo (como Plataforma Java o Microsoft.Net). Con esta arquitectura, se pretende que los componentes software desarrollados sean muy reusables, ya que la interfaz se define siguiendo un estándar; así, un servicio C Sharp podría ser usado por una aplicación Java. 32.

(33) 1.2.5 Concepciones erróneas de SOA: Existe una gran cantidad de mitos y de conceptos erróneos sobre SOA. Algunos de ellos fruto de definiciones un tanto vagas sobre el término, otros son fruto de una excesiva proximidad de quien estudia SOA y tecnologías concretas, lo cual provoca la pérdida de perspectiva global y, con ello, la distorsión del concepto, aunque hay algo imprescindible en este tipo de. arquitectura y es que en ella se tienen que cumplir los principios. previamente mencionados. Alguno de esos conceptos erróneos son los siguientes: •. SOA es una tecnología: SOA es una filosofía de diseño independiente de cualquier compañía, producto, tecnología o tendencia de la industria. Ninguna empresa será capaz de ofrecer una solución SOA completa ya que SOA precisa de la combinación de diversas tecnologías y empresas. Tomar la decisión de destinar toda una inversión en la solución SOA de una única empresa es de por sí un error que hace que dicha inversión carezca de sentido.. •. SOA necesita del uso de Servicios Web: Una arquitectura SOA puede ser implementada mediante el uso de Servicios Web, pero los Servicios Web no son un elemento imprescindible a la hora de implementar SOA.. •. SOA es un concepto nuevo y revolucionario: EDI, CORBA y DCOM son algunos ejemplos de tecnologías cuyos conceptos fundamentales se basan también en la Orientación a Servicios.. •. Para implantar SOA es imprescindible realizar una completa revisión de nuestras tecnologías y procesos de negocio: Una buena implantación SOA debe ser incremental y construirse sobre las bases previas, de modo que no suponga una ruptura sino una mejora gradual.. •. Debemos implantar una arquitectura SOA: SOA es un medio, no un fin en sí misma. Deberemos implantar SOA si y sólo si es realmente necesario y si supone una ventaja competitiva sobre nuestros sistemas actuales, bien porque optimice algunos de nuestros procesos actuales o porque haga posible la implantación de otros nuevos que desde una perspectiva de análisis de negocio hemos considerado necesarios.. 1.2.6 Beneficios de SOA: Los principales aportes de SOA a los Sistemas de Información están relacionados con el logro de una mayor flexibilidad y agilidad. Cada vez más, las distintas áreas de negocio piden a sus departamentos de tecnología respuestas más rápidas para afrontar los retos que tienen planteados. Si no se dispone de una infraestructura preparada resulta prácticamente imposible dar una respuesta adecuada sin incurrir en costes elevados y sin incrementar la complejidad del entorno. Adicionalmente, a medio y largo plazo también 33.

(34) se reducen los costes de desarrollo de las nuevas soluciones debido a la reutilización de servicios.. 1.2.7 Problemas comunes de la adopción de SOA: Uno de los más obvios y comunes retos es el manejo de servicios de metadatos. Los ambientes basados en SOA pueden incluir muchos servicios que intercambian mensajes para realizar tareas. Dependiendo del diseño una simple aplicación puede generar millones de mensajes. Manejar y proveer la información sobre como deben interactuar los servicios puede ser una tarea muy compleja. De igual manera las especificaciones de SOA y Servicios Web están constantemente en expansión, actualización y refinamiento, por lo que hay muy poca gente con el conocimiento y experiencia para trabajar con sistemas SOA. La Interoperabilidad es otro aspecto importante en implementaciones de SOA. Es importante que se tengan en cuenta los estándares desarrollados por la organización WS-I (Servicios Webs) como Basic Profile y Basic Security Profile. De igual manera las herramientas de pruebas desarrolladas por esta organización para asegurar que un servicio cumple con sus estándares. Finalmente se debe tener en cuenta que no todo lo que los vendedores de tecnología SOA lo que están prometiendo es realizable siempre, ya que en algunos casos las expectativas de reducir costos de TI, mejorar agilidad de los sistemas, mejores tiempos de desarrollo y puesta en producción etc., no se obtienen. Es altamente relevante contar con un equipo lo suficientemente preparado (interno y externo) ya que los beneficios potenciales dependen en gran manera del diseño de la arquitectura de los sistemas.. 1.3. Estrategias de desarrollo: Un aspecto muy importante a la hora de comenzar a desarrollar una arquitectura orientada a servicios es la correcta elección de una estrategia de trabajo; es por ello que en este capítulo hacemos un estudio de las distintas estrategias que existe para que a partir del conocimiento de sus características podamos ser capaces de elegir la más adecuada.. 34.

(35) Para solucionar este problema de la gestión del procesamiento penal, necesitamos una estrategia, la cual debe basarse en las prioridades de la organización para establecer el equilibrio correcto entre la entrega y la migración a largo plazo, priorizando las principales necesidades a corto plazo. Tres estrategias comunes han surgido y cada una de ellas puede darnos una solución de este problema de una manera diferente. Estrategias de desarrollo: 1. De arriba hacia abajo 2. De abajo hacia arriba 3. Ágil (o satisfacer-en-el-medio) Estas rutas difieren en las prioridades y consideraciones prácticas. Las tres siguientes secciones ofrecen descripciones de procesos y explora los pros y los contras de cada método. 1. De arriba hacia abajo: Este enfoque no sólo requiere que los procesos de negocio se conviertan en procesos de negocio orientado a servicios, sino que también promueve la creación (o reorganización) del modelo de negocio general. Este proceso está estrechamente vinculado o derivado de la lógica de negocio de la aplicación. La estrategia de arriba abajo apoya la creación de las tres capas del servicio que discutimos en el capítulo anterior.. 35.

(36) Fig.1.10 Estrategia de arriba hacia abajo Paso1: Definir a lo largo de la empresa ontología relevante. Una ontología establece una clasificación de la información procesada por conjuntos de una organización. Esto resulta en un vocabulario común, así como una definición de la forma en que estos conjuntos de información se relacionan unos con otros. Organizaciones más grandes con múltiples áreas de negocio puede tener varias ontologías, que regulan cada una división específica de negocio. Paso2: Alinear los pertinentes modelos de negocios (incluyendo los modelos de entidad) con ontologías nuevas o revisadas. Después de establecida la ontología, los modelos de negocio pueden ser ajustados (o incluso creados) para representar adecuadamente el vocabulario de la ontología del modelado en términos de negocios. Las entidades de modelos son de importancia, ya que después pueden utilizarse como base para la entidad centrada en los servicios empresariales. Paso3: Realizar análisis orientado a servicios. Este paso es descrito con más precisión en el Capítulo2.. Paso4: Realizar diseño orientado a servicios. 36.

(37) Este paso es descrito con más precisión en el Capítulo 3. Paso5: Desarrollar los servicios necesarios. Los servicios se desarrollan de acuerdo con sus respectivas especificaciones de diseño y las descripciones de servicios creadas en el paso 4 Paso6: Prueba de los servicios. La etapa de prueba requiere que todas las operaciones de los servicios se sometan a controles de garantía de la calidad necesaria. Por lo general, esto es superior a la cantidad de pruebas necesarias para la automatización de la lógica, porque está llevando a cabo los servicios reutilizables que probablemente necesiten ser sometidos a pruebas más allá del ámbito inmediato de la solución. Paso7: Despliegue de los servicios. La solución finalmente es desplegarlo en la producción. La ejecución de un examen más allá de los que se realizaron originalmente. Para facilitarles a los solicitantes de servicios múltiples, alta reusabilidad, los servicios puede exigir mayor potencia de procesamiento y pueden tener la seguridad y los requisitos de accesibilidad necesarios. Pros y contras El enfoque de arriba hacia abajo en la construcción de SOA generalmente resulta en una arquitectura de servicios de alta calidad. El diseño y los parámetros en torno a cada uno de los servicios se analizan a fondo, la maximización de la reutilización potencial y las oportunidades para optimizar las composiciones. Los obstáculos a raíz de un enfoque de arriba hacia abajo por lo general están asociados con el tiempo y dinero. Las organizaciones están obligadas a invertir significativamente en el análisis inicial de los proyectos que pueden tener una gran cantidad de tiempo (proporcional al tamaño de la organización y la solución inmediata), sin resultados inmediatos. 2. De abajo hacia arriba: Este enfoque esencialmente fomenta la creación de servicios como medio de aplicación centradas en el cumplimiento de los requisitos. Estos servicios web se basan en un modelo para encapsular lógica de aplicación para poder servir mejor a las necesidades inmediatas de la solución. La integración es el principal motivador para los diseños de 37.

(38) abajo hacia arriba, donde se necesita de aprovechar el marco de comunicaciones abierta SOAP; las cuales pueden ser satisfechas simplemente añadiendo servicios como envoltorios de los sistemas heredados.. Fig.1.11 Estrategia de abajo hacia arriba Paso1: Modelo de solicitud de servicios. Este paso se traduce en la definición de los requisitos de las aplicaciones que pueden cumplirse mediante la utilización de los servicios Web. Requisitos comunes que pueden surgir con la necesidad de sustituir la tecnología tradicional de comunicación a distancia con el marco de comunicaciones de mensajes SOAP. Paso2: Diseño de los servicios de aplicación. Algunos de los servicios de aplicación del modelo obtenidos en el paso 1 pueden ser utilizados por terceros servicios. Estos servicios pueden ofrecer pocas posibilidades de diseño adicional y tendrán que someterse a un proceso de diseño existente que se aplican las normas de diseño para garantizar un nivel de coherencia.. 38.

(39) Paso3: Desarrollo de los servicios de aplicación. Estos servicios se desarrollan de acuerdo con sus respectivas descripciones de servicios y especificaciones de diseño aplicables. Paso4: Prueba de servicios. Los servicios son probados para asegurar que las necesidades de procesamiento puedan ser satisfechas. Rendimiento y pruebas de tensión que a menudo se usan para fijar los parámetros de los sistemas expuestos a través de los servicios de envoltura. Las pruebas de seguridad es también una parte importante de esta etapa. Paso5: Implementación de los servicios. La solución y su aplicación se han desplegado en los servicios de producción. Consideraciones relativas a la aplicación de servicios de aplicación con frecuencia incluyen el rendimiento y los requisitos de seguridad. Pros y contras La mayoría de las organizaciones que actualmente están construyendo los servicios Web aplican el enfoque de abajo arriba. La razón principal detrás de esto es que las organizaciones simplemente pueden añadir servicios Web a sus entornos de aplicaciones existentes para aprovechar esta tecnología. La arquitectura de servicios Web y los servicios de orientación en el que se añaden se mantiene sin cambios, por lo tanto, los principios son raramente tenidos en cuenta. Aunque el diseño de abajo hacia arriba permite la creación eficiente de los servicios Web requerido por las aplicaciones, la implantación de una arquitectura SOA en un momento dado puede necesitar una gran cantidad de reajustes, o incluso la introducción de nuevas capas de servicios. 3. Ágil (o satisfacer-en-el-medio): El desafío sigue siendo encontrar un equilibrio aceptable entre la incorporación de servicios orientados a los principios del diseño en el análisis de los entornos de negocios, sin tener que esperar antes de la integración de las tecnologías de servicios Web en entornos técnicos. Es muy importante encontrar un término medio y esto es posible mediante la definición de un nuevo proceso que permite el análisis a nivel de negocio que 39.

(40) se produzca simultáneamente con la concepción de servicios y el desarrollo.. Fig1.12 Estrategia Ágil. Paso-1: Análisis de arriba abajo: Este análisis comienza centrándose en primer lugar en las partes clave de la ontología y de las entidades empresariales. Las partes de los modelos de negocios relacionados directamente con la lógica del negocio requieren ser automatizadas y tienen. una. prioridad inmediata. 40.

(41) Paso-2: Cuando el análisis de arriba abajo ha progresado suficientemente,. se. realiza el análisis orientado a los servicios: Si bien todavía está en curso el Paso 1, en este paso se inicia una fase de análisis orientado servicio. Dependiendo de la magnitud de los análisis necesarios para completar el paso 1, es aconsejable dar un buen paso en el comienzo. Se podrá determinar si el actual análisis de arriba hacia abajo es lo suficientemente maduro para proceder a la creación de modelos de servicios empresariales. Esta consideración debe ser tomada dada la importancia y la urgencia de las necesidades de los proyectos pendientes. Paso-3: Realizar el diseño orientado al servicio: Se definen las capas de servicios, y los servicios están diseñados como parte de un servicio orientado a proceso de diseño. Los pasos 4, 5 y 6: Desarrollar, probar e implementar los servicios: Desarrollar los servicios y verificar las normas de procedimientos de pruebas y el despliegue. Paso-7: En el análisis de arriba abajo sigue avanzando, revisar los servicios a las empresas: Realizar exámenes periódicos de todos los servicios a las empresas para comparar su diseño contra el estado actual de los modelos de negocio. Tomando. nota de las. discrepancias y creando un nuevo diseño para la mayoría de estos servicios. Por lo general, esto requerirá una ampliación de un servicio existente para que pueda proporcionar las capacidades exigidas. Cuando es rediseñado un servicio, tendrá que someterse de nuevo estándar de desarrollo, prueba y despliegue de medidas. Pros y contras Esta estrategia tiene lo mejor de las dos anteriores, sin poner en peligro la integridad del modelo de negocio de una organización y los servicios orientados a las características de la arquitectura. A pesar de que cumple tanto a corto como a largo plazo, el resultado neto del empleo de esta estrategia es aumentar los esfuerzos asociados a la prestación de cada servicio. 41.

(42) Este enfoque impone tareas de mantenimiento que se requieran para garantizar que los servicios existentes se mantengan en consonancia con los modelos de negocio revisados. Incluso con un proceso de mantenimiento en su lugar, es difícil lograr la alineación con un modelo de negocio que se encuentra en constante cambio.. 1.4.SOA y el modelado de procesos de negocio (BPM) El modelado de procesos de negocio (BPM) es la solución que permite construir procesos de negocio basado en coordinar tantas actividades interactivas (human task), como servicios (system task). Con la aplicación de BPM, las áreas orientan sus necesidades en torno a procesos de negocio, independientemente de la tecnología. Los procesos de negocio se componen de unidades de trabajo bien definidas, con un cometido específico y que debería poder ser aplicable en el contexto de diferentes procesos, en este caso sería la modelación del procesamiento penal realizado por el MININT, en la medida que se desarrolla esta modelación se puede ir avanzando en el desarrollo de una arquitectura SOA. A través de la orientación a servicios o SOA, los procesos de negocio se implementan a través de servicios que ejecutan cada una de las unidades de trabajo mencionadas. Cada servicio es autónomo e independiente del resto. Al no necesitar información de contexto, pueden reutilizares indistintamente en varios procesos. La comunicación con el resto de componentes del proceso se realiza a través de su interfaz, que mientras no sea modificada, permite la mejora continua del servicio disminuyendo la necesidad de realizar continuas pruebas de regresión.. 42.

(43) Conclusiones parciales: Con el paso de tiempo fueron evolucionando un grupo de tecnologías (Sockets, DCOM,etc.) dando lugar a otras mas robustas, como los Servicios Web, que se funcionan muy bien en presencia de proxys y firewalls y son la base tecnológica de las arquitecturas orientadas a servicios. SOA no es una tecnología, sino un paradigma organizativo que permite a las organizaciones unir los objetivos de negocio con la infraestructura de TI integrando los datos y la lógica de negocio de sus sistemas separados. El modelado, la ejecución y la optimización de los procesos de negocio de alto nivel, que involucran a las personas y a los sistemas, son dominio del BPM y como tal, puede ayudar a SOA a obtener mayor valor de sus servicios. Al mismo tiempo, BPM sin la presencia de servicios reutilizables se hace más difícil y menos sencillo de mantener. Sin embargo, el estado actual de la tecnología debe evolucionar para que BPM y SOA se integren lentamente (Volf, 6 abril 2008).. 43.

(44) Capítulo II: Análisis orientado a servicios del sistema de procesamiento penal. El procesamiento penal consiste en una serie de procesos y tareas realizadas en conjunto por varios órganos del ministerio del interior; en este trabajo tiene un peso importante la participación del órgano de la Policía Nacional Revolucionaria (PNR) que es el encargado de todo el proceso de recepción y control de las denuncias así como de la investigación del caso si el delito pertenece a los delitos de menor complejidad. Si el delito es de mediana o mayor complejidad delictiva es atendida por otros órganos. En nuestro trabajo nos centraremos en el análisis del subproceso de la menor complejidad delictiva, que como dijimos anteriormente es el que la PNR procesa e investiga. En este capítulo comenzamos la fase de análisis orientado a servicios aplicando una estrategia ágil pues esta es la que mejor se adapta a las características de nuestro proyecto, donde en poco tiempo debemos implementar una arquitectura orientada a servicios en paralelo con el descubrimiento del modelo de negocios del problema en cuestión.. 2.1. Análisis Orientado a servicios: Como pudimos ver en cualquiera de las estrategias de desarrollo el análisis orientado a servicios Fig.2.1 es un paso fundamental y es por ello que en este apéndice profundizamos en su estudio.. 44.

(45) Fig. 2.1 Un proceso de análisis orientado a servicios. Al comenzar este proceso de análisis lo primero que nos preguntamos es que servicios tienen que ser construidos y que lógica debería ser encapsulada por cada servicio; la medida en que estas preguntas son contestadas se relaciona directamente con la cantidad de esfuerzo invertido en el análisis. A continuación presentamos una serie de pasos que deben ser tenidos en cuenta en la fase de análisis orientado a servicios. Paso1: Definir requisitos del negocio Para empezar este proceso de análisis se requiere la descripción del negocio, siendo muy útil un diagrama del proceso del mismo expresado en la notación de los procesos de negocio (BPMN-Business Process Modeling Notation). Dado que el alcance de nuestro análisis se centra en la creación de servicios en apoyo de una solución orientada a servicios, sólo deben ser considerados los requisitos que puedan. 45.

(46) ser implementados por el sistema. Los requisitos de negocio deben ser lo suficientemente maduros para que pueda ser definido un alto nivel de automatización del proceso. La descripción de este proceso de negocio se utilizará como punto de partida del proceso de modelado de servicios. Descripción del procesamiento de delitos de menor complejidad. Como se puede apreciar en la Fig.2.2; se describe el proceso relacionado con la investigación de un delito de menor complejidad delictiva el cual consta de una serie de pasos estrechamente relacionados entre si, iniciándose con la comprobación preliminar de la ocurrencia del hecho, se envía personal de la PNR para asegurar la existencia del delito y en dependencia de las condiciones encontradas en el lugar del hecho, se enviaran o no las fuerzas correspondientes al lugar de los hechos para así preservar el mismo, después de estas actividades se inicia un subproceso muy importante que es la inspección del lugar del hecho, luego de esta inspección se ejecutan en paralelo varias actividades es decir no es necesario un orden para ser realizadas estas actividades son; la determinación de testigos y otras fuentes de información, someter el peritaje, comprobación de las circunstancias cometidas, determinación del modo empleado en la comisión del hecho, determinación de los prejuicios ocasionados, identificación de la víctima y la determinación del presunto autor. De las actividades anteriores es necesario realizar la documentación de la determinación de testigos y otras fuentes de información así como del peritaje. Después de la determinación del presunto autor se procede con la comprobación del sospechoso y su ambiente, se verifican sus antecedentes para realizar una certificación de los mismo y elaborar un permiso de detención, para proceder con la detención, en caso de que sea habido realizar el proceso investigativo del detenido en un plazo de 72 horas sino es habido entonces se conforma y procede la orden de circulación y se confecciona un documento adicional al atesado.. 46.

(47) Fig.2.2 Procesamiento del delito de menor complejidad. 47.

(48) Paso2: Identificar sistemas automatizados Se identifican algunos sistemas ya automatizados pero que no se adecuan ni son reusables por nuestra arquitectura. Paso3: Conformar modelo de servicios candidatos Los servicios candidatos se identifican a continuación, agrupados en un contexto lógico y siguiendo una secuencia de pasos. El objetivo principal del análisis orientado a servicios en esta etapa es identificar lo que necesitamos para luego diseñar y construir en las siguientes fases del proyecto. Estamos solamente realizando un análisis que resulta una propuesta de la lógica del negocio, la cual será utilizada durante la fase de diseño orientado a servicios, los pasos a seguir pueden verse en la Fig. 2.3.. Fig. 2.3 Obtención de un Modelo de servicios candidatos. 48.

(49) Paso 1: Descomponer el proceso de negocios. Tomamos la documentación del proceso de negocio y lo descomponemos en una serie de subprocesos que respondan a las necesidades de automatización del negocio, en nuestro modelo contamos con dos subprocesos que son la inspección del lugar de hecho, Fig.2.4 y el proceso investigativo del detenido Fig.2.5 los cuales encapsulan lógicas distintas que se encargan de realizar actividades especificas de las cuales depende el proceso general.. Fig.2.4 Proceso de inspección del lugar del hecho. 49.

(50) Fig.2.5 Proceso investigativo del detenido. Paso-2: Identificar operaciones candidatas. En esta etapa debemos identificar cuales serán la operaciones candidatas, las cuales pueden ser realizadas por el sistema o pueden ser consideradas tareas manuales que no requieren ser automatizadas. En el procesamiento de los delitos de menor complejidad hemos identificado dos subprocesos, de los cuales se muestran las operaciones candidatas a continuación. 1-Proceso de inspección del lugar del hecho •. Toma de fotografías del lugar y grabaciones. (Tarea manual). •. Descripción por escrito del lugar del hecho. (Tarea manual) 50.

(51) •. Recopilación de evidencias. (Tarea manual). •. Descripción de los objetos ocupados. (Tarea manual). •. Entrega elementos recopilados. (Tarea manual). •. Plasmar en el libro de recepción lo ocupado. (Tarea del sistema). •. Conformar acta de ocupación. (Tarea manual). •. Archivar acta en el legajo de control(Tarea del sistema). •. Generar copia de orden de registro.(Tarea del sistema). •. Generar copia del acta de ocupación. (Tarea del sistema). •. Poner el acta en el cuerpo de las actuaciones. (Tarea del sistema). 2-Proceso investigativo del detenido •. Interrogatorio. (Tarea manual). •. Realizar fichaje. (Tarea manual). •. Solicitar peritaje psíquico. (Tarea manual). •. Análisis sustancial el proceso(Tarea del sistema). •. Documentar en acata declaraciones del acusado (Tarea del sistema).. •. Documentar peritaje psíquico (Tarea del sistema).. •. Informar a notificación y registro(Tarea del sistema). •. Registrar en el libro de incidencias las presentaciones del acusado en la estación. (Tarea del sistema). •. Comunicar las medidas al área de descubrimiento y trabajo comunitario mediante un acta. (Tarea del sistema). •. Dejar sin efecto la medida luego de su cumplimiento. (Tarea del sistema). •. Comunicar la medida a organizaciones de masa u otras personas que colaboren con su cumplimiento. (Tarea del sistema). Las operaciones anteriormente mencionadas son fruto del análisis de los subprocesos Inspección del lugar del hecho e Investigación del detenido. El modelo general tiene 51.

(52) además otras actividades que están estrechamente relacionadas con estos subprocesos y ellas son: •. Determinación de testigos y otras fuentes de información(Tarea manual). •. Someter a peritaje(Tarea manual). •. Comprobación de las circunstancias cometidas(Tarea manual). •. Determinación del modo empleado en la comisión del hecho (Tarea manual). •. Determinación de los perjuicios ocasionados(Tarea manual). •. Identificación de la victima(Tarea manual). •. Determinación del presunto autor (Tarea manual). •. Comprobación del sospechoso y su ambiente(Tarea manual). •. Realizar certificación de antecedentes(Tarea manual). •. Elaborar permiso de detención(Tarea manual). •. Proceder con la detención (Tarea manual). •. Conformar y proceder con la orden de circulación (Tarea manual). •. Confección de un documento adicional al atesado. (Tarea del sistema). •. Documentar declaraciones (Tarea del sistema). •. Documentar peritaje. (Tarea del sistema). •. Verificación de antecedentes. (Tarea del sistema). •. Confección de de un documento adicional al atesado. (Tarea del sistema). •. Realizar certificación de antecedentes (Tarea del sistema). Paso-3: Abstraer la lógica de orquestación. En caso que se decida construir una capa de orquestación como parte de nuestro SOA, entonces se necesita identificar las partes de la lógica de procesamiento que esta capa podría abstraer (En caso de que no se decida construir una capa de orquestación se omite este paso.). 52.