UNIVERSIDAD CENTRAL DEL ECUADOR

FACULTAD DE INGENIERÍA, CIENCIAS FÍSICAS Y MATEMÁTICA CARRERA DE INGENIERÍA EN INFORMÁTICA

DESARROLLO E IMPLEMENTACION DEL SISTEMA DE APLICACIONES EMPRESARIALES ORACLE CON J2EE UTILIZANDO WEBLOGIC, AUTENTICACION DE USUARIOS A APLICACIONES CON LDAP Y GESTION DE VERSIONES DESPLEGADAS EN EMERGE-SOFT

TRABAJO DE GRADUACIÓN PREVIO A LA OBTENCIÓN DEL TITULO DE INGENIERO INFORMÁTICO

AUTORES: BETANCOURT CABEZAS, MIGUEL ANGEL ORDOÑEZ TACO, CARLOS LUIS

TUTOR: ING. MONCAYO UNDA, MILTON GIOVANNY

Quito, Mayo 12, 2016

i

AGRADECIMIENTO

Mis agradecimientos infinitos para mi padre, madre, familiares, maestros y amigos quienes me han tenido confianza, y me han apoyado durante todo este tiempo; gracias por su ayuda, compresión y colaboración en cada una de las etapas de mí proyecto para todos ustedes gracias.

Expreso mi agradecimiento a Giovanny Moncayo Ingeniero Informático y Tutor del Trabajo Integrador, por sus valiosas orientaciones.

Hugo Zumárraga Gerente y Director del Área de Tecnología de eMerge-Soft, por su constante apoyo hacia este trabajo.

Miguel Angel Betancourt Cabezas

ii

AGRADECIMIENTO

Agradezco a mis padres Carlos Ordóñez y María Taco por ser los principales promotores de mis sueños, gracias a ellos por cada día confiar y creer en mí y en mis expectativas, gracias a mi madre por su paciencia y amor siempre está conmigo en cada paso que doy, gracias a mi padre por sus consejos que me guían durante mi vida.

A mis hermanos Martha y Sebastián por estar siempre junto a mí y por brindarme su apoyo. Y a mi familia en general, porque me han brindado su apoyo incondicional y por compartir conmigo buenos y malos momentos.

A la vez expresar mi agradecimiento a Giovanny Moncayo Ingeniero Informático y Tutor del Trabajo Integrador, por sus valiosas orientaciones.

Hugo Zumárraga Gerente y Director del Área de Tecnología de eMerge-Soft, por su constante apoyo hacia este trabajo.

Carlos Luis Ordóñez Taco

iii

AUTORIZACIÓN DE LA AUTORÍA INTELECTUAL

Nosotros MIGUEL ANGEL BETANCOURT CABEZAS, CARLOS LUIS ORDOÑEZ TACO en calidad de autores del trabajo Integrador: DESARROLLO E IMPLEMENTACION DEL SISTEMA DE APLICACIONES EMPRESARIALES ORACLE CON J2EE UTILIZANDO WEBLOGIC, AUTENTICACION DE USUARIOS A APLICACIONES CON LDAP Y GESTION DE VERSIONES DESPLEGADAS

EN EMERGE-SOFT, autorizamos a la

Universidad Central del Ecuador hacer uso de todos los contenidos que nos pertenece o parte de lo que contiene esta obra, con fines estrictamente académicos o de investigación. Los derechos que como autores nos corresponden, con excepción de la presente autorización, seguirán vigentes a nuestro favor, de conformidad con lo establecido en los artículos 5, 6, 8, 19 y demás pertinentes de la Ley de Propiedad Intelectual y su Reglamento. Asimismo, autorizamos a la Universidad Central del Ecuador para que realice la digitalización y publicación de este trabajo integrador en el repositorio virtual, de conformidad a lo dispuesto en el Art. 144 de la Ley Orgánica de Educación Superior.

Quito, 06/Mayo/2016

Miguel Angel Betancourt Cabezas

Carlos Luis Ordoñez Taco

C. C.: 1724552904

C. C.: 0604977082

Teléfonos: 2358145 / 0988198248

Teléfonos: 2600631 / 0991895822

[email protected]

[email protected]

iv

CERTIFICACION DEL TUTOR

Yo, MILTON GIOVANNY MONCAYO UNDA en calidad de tutor del trabajo integrador DESARROLLO

E

IMPLEMENTACION

DEL

SISTEMA

DE

APLICACIONES

EMPRESARIALES ORACLE CON J2EE UTILIZANDO WEBLOGIC, AUTENTICACION DE USUARIOS A APLICACIONES CON LDAP Y GESTION DE VERSIONES DESPLEGADAS

EN EMERGE-SOFT, elaborado por los estudiantes MIGUEL ANGEL

BETANCOURT CABEZAS Y CARLOS LUIS ORDOÑEZ TACO de la Carrera de INGENIERIA INFORMATICA, Facultad de INGENIERIA EN CIENCIAS FISICAS Y MATEMATICA de la Universidad Central del Ecuador, considero que el mismo reúne los requisitos y méritos necesarios en el campo metodológico y en el campo epistemológico, para ser sometido a la evaluación por parte del jurado examinador que se designe, por lo que lo APRUEBO, a fin de que trabajo integrador sea habilitado para continuar con el proceso de titulación determinado por la Universidad Central del Ecuador. En la ciudad de Quito, a los 8 días del mes Abril de 2016.

ING. Milton Giovanny Moncayo Unda CC: 171893333383

v

APROBACIÓN DE REVISORES

vi

vii

CONTENIDO pág.

AGRADECIMIENTO.................................................................................................................... i CERTIFICACION DEL TUTOR ................................................................................................. v APROBACIÓN DE REVISORES ............................................................................................... vi RESUMEN.................................................................................................................................. xii ABSTRACT ............................................................................................................................... xiii 1

2

INTRODUCCION ................................................................................................................ 1 1.1

Antecedentes ................................................................................................................. 1

1.2

Objetivo General ........................................................................................................... 2

1.3

Objetivos Específicos .................................................................................................... 2

1.4

Justificación................................................................................................................... 2

1.5

Alcance .......................................................................................................................... 3

MARCO TEORICO .............................................................................................................. 4 2.1

Servidores de Aplicaciones ........................................................................................... 4

2.2

Oracle WebLogic .......................................................................................................... 6

2.3

Protocolo Ligero de Acceso a Directorios o LDAP ...................................................... 7

2.3.1 2.4

Control de Versiones ................................................................................................... 12

2.4.1 3

Definiciones ........................................................................................................ 13

METODOLOGÍA DE DESARROLLO .............................................................................. 15 3.1

4

Sistema de Nombres de Dominio o DNS .............................................................. 9

Metodología de Gestión de Proyecto ......................................................................... 15

IMPLEMENTACION ......................................................................................................... 19 4.1

Software de DNS y LDAP ......................................................................................... 19

4.1.1

Software DNS ..................................................................................................... 19

4.1.2

Software de LDAP .............................................................................................. 21

4.1.3

Gestión de Usuarios de LDAP ............................................................................ 23

4.2

Integración WebLogic con Open LDAP ..................................................................... 24

4.3

Implementación de Seguridades.................................................................................. 28

4.3.1

Seguridad de Usuario y Roles a través del Directorio LDAP ............................. 28

4.3.2

Seguridad de Usuario y Roles a través de la Aplicación ..................................... 28

4.3.3

Seguridad a través de esquema de Base de Datos ............................................... 28

4.4

Administración y control de versiones ........................................................................ 29 viii

4.4.1 4.5

Arquitectura................................................................................................................. 33

4.5.1 5

Ámbito de Aplicación ......................................................................................... 29 Diagrama de Arquitectura de distribución de Equipos........................................ 34

CONCLUSIONES Y RECOMENDACIONES .................................................................. 35 5.1

CONCLUSIONES ...................................................................................................... 35

5.2

RECOMENDACIONES ............................................................................................. 36

6

BIBLIOGRAFIA ................................................................................................................. 37

7

ANEXO A ............................................................................................................................. 2 Manual de configuración de BIND como Servidor de DNS. .................................................... 2

8

ANEXO B ........................................................................................................................... 11 Manual de configuración de OpenLDAP como Servidor LDAP. ........................................... 11

9

ANEXO C ........................................................................................................................... 23 Manual de configuración de conexión a administración de LDAP ......................................... 23

10

ANEXO D ....................................................................................................................... 26 Manual de Definición de Usuarios en LDAP.......................................................................... 26

11

ANEXO E ....................................................................................................................... 30 Manual de Instalación Ambiente Oracle Web Logic y Application Development Framework ................................................................................................................................................. 30

12

ANEXO F........................................................................................................................ 61 Manual de despliegue de la aplicación ................................................................................... 61

13

ANEXO G ....................................................................................................................... 75 Manual de Integración WebLogic con Open LDAP ............................................................... 75

14

ANEXO H ....................................................................................................................... 83 Manual de Gestión de Versiones ............................................................................................. 83

15

ANEXO I ........................................................................................................................ 91 Manual de Instalación VisualSVN Server .............................................................................. 91

16

ANEXO J ........................................................................................................................ 95 Manual de Instalación TortoiseSVN ....................................................................................... 95

17

ANEXO K ....................................................................................................................... 98 Manual de creación de usuarios y grupos en VisualSVN Server ............................................ 98

18

ANEXO L ..................................................................................................................... 101 Solicitud de Proyecto ............................................................................................................ 101

19

ANEXO M .................................................................................................................... 102 Certificado de Aceptación y Conformidad de Proyecto Integrador ...................................... 102

ix

LISTADO DE ILUSTRACIONES

Ilustración 1. Arquitectura de un sistema de aplicaciones web ..................................................... 5 Ilustración 2. Ejemplo de aplicaciones SOA ................................................................................. 7 Ilustración 3. Estructura de Dase de Datos DNS y Sistema de Archivos Unix .......................... 11 Ilustración 4. Flujo de Proceso SCRUM ..................................................................................... 18 Ilustración 5. Características de Servidor LDAP ........................................................................ 21 Ilustración 6. Características de Servidor LDAP ........................................................................ 22 Ilustración 7. Apache Directory Studio ....................................................................................... 23 Ilustración 8. Diagrama de Integración WebLogic – LDAP ....................................................... 25 Ilustración 9. Usurios obtendios de OpenLDAP ......................................................................... 26 Ilustración 10. Grupos obtenidos de OpenLDAP ........................................................................ 26 Ilustración 11. Pantalla de Logeo de la aplicación ...................................................................... 27 Ilustración 12. Inicio de Sesión Satisfactoriamente .................................................................... 27 Ilustración 13. Arquitectura para el control de versiones ........................................................... 32 Ilustración 14. Diagrama de Repositorio Subversion .................................................................. 32 Ilustración 15. Arquitectura de Red ............................................................................................ 34

x

LISTADO DE TABLAS

Tabla 1. Comparación de las metodologías tradicionales y ágiles . ............................................ 16 Tabla 2. Comparación de las metodologías SCRUM y PMBOK ............................................... 17 Tabla 3. Comparación de Software de DNS ............................................................................... 20 Tabla 4. Esquemas de seguridades aplicaciones eMerge-Soft .................................................... 29 Tabla 5. Comparación entre CVS y Subversion.......................................................................... 31 Tabla 6. Distribución de equipos................................................................................................. 34

xi

RESUMEN

TEMA: “DESARROLLO E IMPLEMENTACION DEL SISTEMA DE APLICACIONES EMPRESARIALES ORACLE CON J2EE UTILIZANDO WEBLOGIC, AUTENTICACION DE USUARIOS A APLICACIONES CON LDAP Y GESTION DE VERSIONES DESPLEGADAS EN EMERGE-SOFT, MODELO PROYECTO INTEGRADOR” Autores: Miguel Angel Betancourt Cabezas Carlos Luis Ordoñez Taco Tutor: Milton Giovanny Moncayo Unda

La empresa eMerge-Soft se vio en la necesidad de realizar un mejoramiento para el control de versiones de sus aplicaciones desarrolladas, e integrar un servidor OpenLDAP con WebLogic para la autenticación de usuarios a las aplicaciones.

Por lo que se instaló y configuró un servidor de versiones central para controlar los históricos correspondientes a los cambios de cada uno de los desarrolladores, un DNS para la definición de un Dominio y un LDAP para la gestión de usuarios. Además se realizó la integración entre el servidor de aplicaciones con el de autenticación, permitiendo así que los usuarios finales de las aplicaciones se autentiquen a través de sus credenciales registradas en LDAP.

Hoy en día eMerge-Soft cuenta con un ambiente integrado para que los usuarios se autentiquen a las aplicaciones usando su respectiva credencial registrada en un LDAP, y además tiene un control sobre los cambios que realizan sus desarrolladores en los programas fuentes.

PALABRAS CLAVES: LDAP / SERVIDOR DE AUTENTICACION / SERVIDOR DE VERSIONES / WEBLOGIC.

xii

ABSTRACT

SUBJECT: “DEVELOPMENT AND IMPLEMENTATION OF A SYSTEM TO SUBMIT APPLICATIONS WITH COMPANIES ORACLE WITH J2EE BY USING WEBLOGIC, AUTHENTICATION OF USERS TO APPLICATIONS WITH LDAP AND MANAGEMENT OF VERSIONS DEPLOYED IN EMERGE-SOFT, INTEGRATING PROJECT MODEL” Authors: Betancourt Cabezas Miguel Angel, Ordóñez Taco Carlos Luis Tutor: Milton Giovanny Moncayo Unda

eMerge-Soft Company was faced to the need to improve control of versions of developed applications and integrate OpenLDAP server with WebLogic with users authentication for applications. A central versions server was installed and configured to control historic for changes for each of developers, a DNS to define a Domain and a LDAP for users’ management. Additionally, integration was made between the applications server with the authentication, in order to allow final users of applications to be authenticated through credential registered in LDAP. Currently eMerge-Soft Company is provided of an integrated environment for users to authenticate applications by using the relevant credential registered in LDAP, and additionally a control on changes made by developers in sources programs. KEYWORDS: LDAP/ AUTHENTICATION SERVER / VERSIONS SERVER/ WEBLOGIC.

I certify that I am fluent in both English and Spanish languages and that I have translated the attached abstract from the original in the Spanish language to the best of my knowledge and belief.

Ernesto Andino G. Translator IC:1703852317

xiii

xiv

1

INTRODUCCION

Actualmente dentro de la organización eMerge-Soft surgieron las necesidades de implantar un nuevo mecanismo que permita gestionar de manera centralizada los archivos fuente que corresponden a versiones de las aplicaciones desarrolladas por parte del equipo de programación, puesto que el integrar el código escrito por múltiples programadores en un solo paquete se tornó en una tarea que alargaba los tiempos. El centralizar los programas fuentes le permite conocer que archivos fueron modificados por cada uno de los programadores y por ende realizar la entrega de los productos a los clientes dentro de los tiempos establecidos.

Por otro lado, el integrar un servidor OpenLDAP con WebLogic lo cual permite que los usuarios se autentiquen a múltiples aplicaciones a través de credenciales registradas previamente en el mismo, puesto que esta debe ajustarse a las necesidades de los clientes de eMerge-Soft que usan a LDAP como un proveedor de autenticación.

1.1 Antecedentes

El equipo de desarrollo de eMerge-Soft al no contar con un mecanismo centralizado de los códigos fuente, creó su propio mecanismo que le permite replicar los cambios que se hayan realizado en una aplicación, y esto es un usuario de desarrollo ejecuta cambios en la aplicación local de su ordenador, las prueba y finalmente los mismos cambios los debe replicar en una versión de despliegue que la gestiona el líder del equipo de desarrollo. La versión de despliegue una vez aplicados los cambios que haya realizado todo el equipo de desarrollo es puesta a prueba y si la misma no presenta ningún error es puesta en producción. Esto no ha sido nada beneficioso para eMerge-Soft puesto que esto toma más de los tiempos planificados para la entrega de un producto a sus clientes.

1

Por otro lado está la autenticación de usuarios a las aplicaciones, actualmente existen clientes que dentro de sus organizaciones cuentan con un servidor de directorio de acceso LDAP como OpenLDAP que es Open Source, y les permite reducir costos por licenciamiento, o que a su vez sus usuarios utilizan una misma cuenta para acceder a las múltiples aplicaciones con las que dispone la organización, para lo cual es necesario que las aplicaciones de eMerge-Soft se integren fácilmente con este servidor a la hora de realizar la autentificación.

1.2 Objetivo General



Integrar un conjunto de herramientas que le permita facilitar al equipo de eMerge-Soft, el desarrollo de aplicaciones.

1.3 Objetivos Específicos



Instalar y configurar un gestor de versiones.



Integrar WebLogic (Servidor de Aplicaciones) con OpenLDAP proveedor de grupos y usuarios para la autenticación de usuarios en aplicaciones desplegadas.

1.4 Justificación

El proyecto se realizará para ayudar a gestionar las versiones de las aplicaciones desarrolladas por la empresa eMerge-Soft, el mismo que incluirá la instalación y configuración de un gestor de versionamiento, y así tener un control sobre los cambios que realicen los programadores. Además, el poder ofrecer a los clientes que las aplicaciones usen como método de autenticación a un servidor de LDAP, facilitando así el uso de una sola credencial registrada en OpenLDAP para las múltiples aplicaciones de la organización, por ende se instalará, configurará e integrará un servidor OpenLDAP con WebLogic.

2

1.5 Alcance

Se implementará y configurará una herramienta que permite gestionar el control de versiones de las aplicaciones realizadas por la empresa, esto conlleva a crear un repositorio centralizado para almacenar todas las versiones y llevar un histórico de los cambios.

Se realizará la configuración correspondiente para integrar el servidor de aplicaciones Oracle WebLogic con un servidor LDAP OpenLDAP, el cual nos permita gestionar la autentificación de usuarios a las aplicaciones desarrolladas por eMerge-Soft.

Para realizar la autentificación se necesitará que el usuario este registrado tanto en el servidor LDAP como en el servidor de aplicaciones para poder obtener la contraseña desde dicho servidor al momento de ingresar a la aplicación.

Cabe destacar que el Módulo de Seguridades que se usará en el presente proyecto será entregado por el equipo de desarrollo de eMerge-Soft para su respectivo despliegue y configuración en el servidor de aplicaciones WebLogic.

3

2

MARCO TEORICO

2.1 Servidores de Aplicaciones

Los servidores de aplicaciones trabajan en conjunto con los servidores web para que el proceso se haga de forma transparente al usuario; es decir el usuario pide el servicio a través, normalmente, de su navegador y el servidor web atiende la petición y pide al servidor de aplicaciones la traducción de la aplicación contenida a fin de mostrar al usuario el resultado de forma entendible por su navegador (es decir en formato HTML).

A la forma de trabajar de un servidor de aplicaciones, se le conoce normalmente como arquitectura de tres capas (a veces se habla de más capas). 

Una primera capa es la del navegador que es capaz de traducir el llamado código del lado del cliente (HTML, JavaScript, CSS, Flash,…).



La segunda capa la forma el servidor de aplicaciones en su labor de traducir código en el lado del servidor (JSP, PHP, Ruby on Rails, Cold Fussion…) y convertirlo al formato entendible por el navegador.



La tercera capa son todos los servicios a los que accede el servidor de aplicaciones que necesita para poder realizar la tarea encomendada a la aplicación (por ejemplo el acceso a la base de datos). (Sánchez, 2012)

4

Ilustración 1. Arquitectura de un sistema de aplicaciones web (Sánchez, 2012)

La Ilustración 1 muestra una arquitectura de tres capas para resolver la petición de una página PHP.

Como consecuencia del éxito del lenguaje de programación Java, el término servidor de aplicaciones usualmente hace referencia a un servidor de aplicaciones Java EE.

El estándar J2EE permite el desarrollo de aplicaciones empresariales de una manera sencilla y eficiente. Una aplicación desarrollada con las tecnologías J2EE permite ser desplegada en cualquier servidor de aplicaciones o servidor web que cumpla con el estándar. Un servidor de aplicaciones es una implementación de la especificación J2EE

Entre los servidores de aplicación Java EE privativos más conocidos se encuentran: 

WebLogic de Oracle (antes BEA Systems) .- Oracle WebLogic es un servidor de aplicaciones Java EE (J2EE) y también un servidor web HTTP, desarrollado por BEA Systems, posteriormente adquirida por Oracle Corporation. Se ejecuta en Unix, Linux, Microsoft Windows, y otras plataformas. (Oracle, 2016)

5



WebSphere de IBM. un servidor de aplicaciones de software, es el producto estrella dentro de la familia WebSphere de IBM. WAS está construido usando estándares abiertos tales como J2EE, XML, y Servicios Web. Varios laboratorios de IBM alrededor del mundo participaron en la creación de los productos run-time WebSphere y las herramientas de desarrollo. (IBM, 2016)



WildFly.- anteriormente conocido como JBoss AS, o simplemente JBoss, es un servidor de aplicaciones Java EE de código abierto implementado en Java puro, más concretamente la especificación Java EE. Al estar basado en Java, JBoss puede ser utilizado en cualquier sistema operativo para el que esté disponible la máquina virtual de Java. JBoss Inc. (Red Hat, 2013)



GlassFish de Oracle.- es un servidor de aplicaciones de software libre desarrollado por Sun Microsystems, compañía adquirida por Oracle Corporation, que implementa las tecnologías definidas en la plataforma Java EE y permite ejecutar aplicaciones que siguen esta especificación. (Oracle, 2016)



Apache TomEE.- Apache TomEE es la edición Java EE de Apache Tomcat, el cual combina varios proyectos Java incluyendo Apache OpenEJB, ApacheOpenWebBeans, Apache OpenJPA, ApacheMyFaces y otros. El proyecto tiene una certificación de la corporación Oracle como un servidor compatible del perfil web Java EE 6, que es una parte de toda la especificación Java EE. (Software, 2016)

2.2 Oracle WebLogic

Oracle WebLogic Server es una solución escalable, basada en la plataforma Java Enterprise Edition (Java EE) Versión 7.0 del servidor de aplicaciones. La infraestructura de servidor WebLogic apoya el despliegue de muchos tipos de aplicaciones distribuidas y es ideal para la creación de aplicaciones basadas en Arquitecturas Orientadas a Servicios (SOA) obsérvese la Ilustración 2.

6

Ilustración 2. Ejemplo de aplicaciones SOA (Sánchez, 2012)

Oracle WebLogic Server 12c es un servidor de aplicaciones, tanto en entornos convencionales como en la nube. Con Oracle WebLogic puede crear aplicaciones de vanguardia en una plataforma en la nube, lo que simplifica las operaciones con la administración de nube nativa y acelera el lanzamiento al mercado con una plataforma de desarrollo moderna y herramientas integradas.

Oracle WebLogic Server 12c proporciona flexibilidad entre las nubes en las instalaciones y las de terceros, y está optimizado para Oracle Exalogic Elastic Cloud. Como la piedra angular de Oracle Cloud Application Foundation, Oracle WebLogic Server proporciona un desempeño de nube extremo, escalabilidad y elasticidad, integración sin precedentes con Oracle’s Database 12c incluido el soporte para bases de datos de tenencia múltiple y permite aumentar la productividad del desarrollador con el desarrollo de aplicaciones móviles y el soporte de Maven, lo que hace de Oracle el líder de la participación de mercado en la industria. (Oracle, 2016).

2.3 Protocolo Ligero de Acceso a Directorios o LDAP

El Protocolo Ligero de Acceso a Directorios o LDAP por sus siglas en Ingles – Lightweight Directory Access Protocol – permite acceder a servicios de directorio. El potencial de LDAP es consolidar servicios existentes dentro de un solo directorio que pueden ser accedidos por clientes de LDAP desde varios vendedores. (Carter, 2003). Los clientes pueden ser navegadores WEB,

7

clientes de correo, servidores de correo o cualquiera de múltiples aplicaciones. Ejemplos de este tipo de herramientas son entre otros: 

Active Directory de Microsoft.- Active Directory Lightweight Directory Services (AD LDS) es un servicio de directorio Lightweight Directory Access Protocol (LDAP) que proporciona soporte flexible para las aplicaciones habilitadas para directorios (Microsoft, 2016) . Active Directory Domain Services (AD DS) es una base de datos de propósito especial. El directorio está diseñado para manejar un gran número de operaciones de lectura y de búsqueda, y un número significativamente menor de los cambios y actualizaciones. Los datos de AD son jerárquicos, replicados y extensibles. La base de datos de AD se compone de objetos y atributos. AD contiene tres particiones, entre ellas la partición de dominio que contiene los usuarios, grupos, contactos, equipos, unidades organizacionales, y muchos otros tipos de objetos (MSDN, 2016).



Slapd de University of Michigan.- Slapd es un servidor de directorio LDAP que se ejecuta en muchas plataformas UNIX diferentes. Se puede utilizar para proporcionar un servicio de directorio de su propio. Su directorio puede contener casi cualquier cosa que usted quiere poner en él. Se puede conectar al servicio de directorio LDAP global, o ejecutar un servicio por sí mismo (Michigan, 2016).



OpenLDAP basado en Slapd.- es una implementación open source que soporta y permite la gestión de usuarios y grupos de directorios a través del protocolo LDAP. (The OpenLDAP Foundation, 2014).

El consolidar la información dentro de un solo directorio, no solo estamos colocando el contenido de una multitud de pequeños recipientes dentro de un gran contenedor. El organizar nuestra información bien y pensada cuidadosamente acerca de la necesitada por las aplicaciones de los clientes, nosotros podemos reducir la redundancia de datos en nuestros directorios y por consiguiente reducir los gastos administrativos excedidos necesitados para gestionar aquellos datos.

El modelo de información de LDAP está basado en entradas. Una entrada es una colección de atributos un único y global Nombre Distinguido o DN por sus siglas en Ingles – Distinguished Name. El DN es usado para referir a una entrada sin ambigüedades (The OpenLDAP Foundation, 2014). Cada tipo de los atributos de la entrada tiene uno o más valores. Los tipos son típicamente cadenas mnemotécnicas, como “cn” para un nombre común, o “mail” para una dirección de correo. Así, se puede guardar la información de usuarios como por ejemplo, su nombre completo,

8

dirección de correo electrónico, teléfonos, entre otra información del usuario, a la misma que puede ser accedida por clientes de LDAP.

Para definir un Servidor LDAP es necesario contar con un servidor DNS, así a continuación se describen sus conceptos básicos.

2.3.1

Sistema de Nombres de Dominio o DNS

El Sistema de Nombres de Domino o DNS por sus siglas en Inglés – Domain Name System – permite traducir el nombre descriptivo de un recurso a su dirección de red física; esto facilita que cada recurso asignado con una dirección IP única, dentro de una red local o global, sea accedida cada vez que queramos a través de su correspondiente nombre sin la necesidad de conocer su dirección IP física (Aitchison, 2011). Ejemplos de este tipo de herramienta son entre otros: 

BIND de Internet Systems Consortium.- Es un software de DNS que permite el control local de la base de datos del dominio. (Liu & Albitz, 2006)



Microsoft DNS.- El cual está integrado con Active Directory. El rol de servidor DNS en Windows Server 2008 combina el soporte para los protocolos estándar de DNS con los beneficios de la integración con los servicios de dominio de Active Directory (AD DS) y otras redes y seguridad de las características de Windows, incluyendo capacidades avanzadas tales como la actualización dinámica segura de registros de recursos DNS (Microsoft, DNS Overview, 2016).



DBNDNS.-

Es un contenedor del paquete djdns, una colección de herramientas del

Sistema de Nombres de Dominio, el mismo que ofrece cache de DNS, puede definirse como un servidor DNS de propósito general, incluye una biblioteca de cliente DNS, entre otras herramientas de DNS para los administradores de DNS (Debian, 2015).

El Sistema de Nombres de Domino es una base distribuida. Esta estructura permite el control local de los segmentos de la base de datos global, sin embargo los datos en cada segmento está disponible en toda la red a través de un esquema cliente/servidor. (Liu & Albitz, 2006).

9

2.3.1.1 Cuando Usar DNS

Sobre el uso de un servidor de nombres (Liu & Albitz, 2006) sugieren tomar en cuenta los siguientes puntos los mismos que pueden ayudar a elegir o no el configurar un servidor DNS dentro de una red, así:

“Si estas conectado a la Internet.”, sugieren que no es necesario si se tiene un número manejable de hosts, o que a su vez se puede contratar el servicio para que se organicen nuestras zonas. Mientras que si se tiene un gran número de hosts recomiendan configurar un servidor DNS para definir nuestras propias zonas y que sean administradas por nosotros mismos.

“Si tienes tu propio internet basado en TCP/IP.. ”, sugieren configurar un servidor DNS si nosotros contamos con una gran variedad de hosts dentro de una red compleja o “red de redes”, de tal manera que nos ayude a simplificar la distribución de la información de los hosts.

“Si tienes tu propia red de área local o red de sitios..” mencionan que no es necesario un servidor DNS si la red no está conectada a una red mayor y sugieren usar otros sistemas como Windows Internet Name Service (WINS) de Windows o tablas de equipos. Mientras que sugieren configurar zonas si necesitamos administración distribuida o, si nuestra red está conectada a otras redes como a nuestro internet corporativo o a la Internet.

2.3.1.2 Dominios y Delegación El Sistema de Nombres de Dominio – DNS usa un árbol o jerarquía de estructura de nombres, en la cual el nivel superior del árbol es el nodo raíz, seguido por los Dominios de Nivel Superior o TLDs del inglés Top-Level Domains, luego por los Dominios de Segundo – Nivel o SLDs del inglés Second-Level Domains, y por cualquier otro número de nivel más bajo, cada uno separado por un punto (Aitchison, 2011). Ejemplo: www.midominio-sld.tld La estructura de la base de datos del DNS, mostrada en la Ilustración 3, es similar a la estructura de un sistema de archivos. La base de datos global es representada como un árbol invertido, con el nodo raíz en la parte superior. Cada nodo en el árbol tiene una etiqueta de texto, la cual identifica

10

al nodo relativo a su padre; cada nodo es también la raíz de un nuevo subárbol del árbol global (Aitchison, 2011).

Ilustración 3. Estructura de Dase de Datos DNS y Sistema de Archivos Unix (Aitchison, 2011)

A continuación de acuerdo a los autores (Liu & Albitz, 2006) se describen los primeros dominios de nivel superior que dividen el espacio de nombres de dominio de la Internet organizativamente en siete dominios: 

com: para organizaciones comerciales.



edu: para organizaciones educativas.



gov: para organizaciones gubernamentales.



mil: para organizaciones militares.



net: antiguamente organizaciones que proporcionaban infraestructura de red, hoy en día abierta para cualquier organización comercial, como lo es com.



org: antiguamente para organizaciones no comerciales, hoy abierta.



int: para organizaciones internacionales.(p17 –p18)

La principal meta del diseño del Sistema de Nombres de Dominio es descentralizar la administración, la misma que es resuelta a través de la delegación. Delegando dominios funciona muy similar a delegar tareas en el trabajo. Un administrador podría dividir un gran proyecto dentro de tareas más pequeñas y delegando responsabilidad para cada una se estas tareas a diferentes empleados. Igualmente, una organización que administra un dominio puede dividirlo dentro de subdominios (Liu & Albitz, 2006). 11

Cada subdominio tiene un nombre único y puede ser delegado a otras organizaciones, lo cual significa que una organización llega a ser responsable por el mantenimiento de toda la información en ese subdominio.

2.3.1.3 Zonas y Archivos de Zonas Los servidores de Nombres soportan lo que se denominan “zonas”. El termino zona y su relación con un nombre de dominio puede ser confuso. Una zona es descrita usando un archivo de zonas que traduce el nombre del dominio dentro de entidades operacionales, como son hosts, servidores de correos, servicios y otras características para el uso por el software de DNS (Liu & Albitz, 2006).

2.4 Control de Versiones

Se llama control de versiones a la gestión de los diversos cambios que se realizan sobre los elementos de algún producto o una configuración del mismo, esto quiere decir cambio o modificaciones a archivos de un directorio. Una versión, revisión o edición de un producto, es el estado en el que se encuentra el mismo en un momento dado de su desarrollo o modificación.

Aunque un sistema de control de versiones puede realizarse de forma manual, es muy aconsejable disponer de herramientas que faciliten esta gestión dando lugar a los llamados sistemas de control de versiones o VCS (del inglés Version Control System). Estos sistemas facilitan la administración de las distintas versiones de cada producto desarrollado, así como las posibles especializaciones realizadas (por ejemplo, para algún cliente específico). Ejemplos de este tipo de herramientas son entre otros: 

CVS.- es un sistema de control de versiones, un componente importante de la gestión de la configuración de fuente (SCM). Con ella, se puede registrar la historia de archivos de fuentes y documentos. Se llena un papel similar al del software libre RCS, SPMLR , y Aegis paquetes. CVS es un sistema de calidad de la producción de amplio uso en todo el mundo, incluyendo muchos proyectos de software libre. (Wikipedia, 2015)



Subversion.- Subversion usa una base de datos central que contiene todos los archivos cuyas versiones se controlan y sus respectivas historias. Ésta base de datos se conoce

12

como el repositorio. El repositorio normalmente yace en un servidor de archivos ejecutando el servidor de Subversion, que provee a pedido el contenido a los clientes de Subversion (como TortoiseSVN, por ejemplo). Si solo puede hacer una copia de seguridad de una sola cosa, hágala del repositorio, ya que es la copia maestra de toda su información. (TortoiseSVN, 2015) 

Git.- es un software de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen un gran número de archivos de código fuente. Al principio, Git se pensó como un motor de bajo nivel sobre el cual otros pudieran escribir la interfaz de usuario o front end como Cogito o StGIT. (Wikipedia, 2015)



Mercurial.- Mercurial gestiona de manera eficaz los proyectos de cualquier tamaño y tipo. Cada clon contiene toda la historia del proyecto, por lo que la mayoría de las acciones son locales, rápida y cómoda. Mercurial es compatible con una multitud de flujos de trabajo y se puede mejorar fácilmente su funcionalidad con extensiones. (Mercurial, 2016)

El control de versiones se realiza principalmente en la industria informática para controlar las distintas versiones del código fuente dando lugar a los sistemas de control de código fuente o SCM (por sus siglas en inglés Source Code Management).

2.4.1 Definiciones



Repositorio Central: El proceso de Administración de Fuentes, Ejecutables y Documentación se basa en la existencia de un repositorio central donde se almacena y cataloga todo el código fuente, ejecutables y documentación de los sistemas y aplicativos existentes en eMerge-Soft. Este repositorio central tendrá siempre el historial y la última versión de los programas y documentación de las aplicaciones desarrolladas e implementadas. Será el único sitio de donde se podrán tomar los archivos para su revisión y/o modificación.



Estructura del Repositorio Central: Estará conformado por repositorios de Subversion, Directorios Compartidos y Máquinas Virtuales.

13



Revisión: Número que identifica el último cambio de cada archivo en el repositorio. Un archivo se entregará con su correspondiente número de revisión.



Directorio de Trabajo: De acuerdo a las reglas de acceso, el personal podrá crear una copia local. Este directorio de trabajo podrá ser auditado e incluso eliminado ya que lo único existente para eMerge-Soft son los repositorios y directorios



Ejecutables: Los ejecutables se generan a partir de los programas fuentes de una revisión específica en el repositorio. Estos ejecutables se almacenan en el repositorio.



Solicitud Cambios: Requerimiento realizado por el usuario, donde se define los cambios o mejoras que se requiere para uno o varios aplicativos. La solicitud de cambio incluye la persona responsable de los entregables y se encuentra en el repositorio con su correspondiente identificación y revisión para guardar la trazabilidad de dicha solicitud.



Autorización de Cambio: Autorización Cambio Producción, lo realiza el administrador responsable o gerente de cada proyecto y es su responsabilidad gestionar cualquier requerimiento pre o post producción de dicha actualización. toda autorización cambio producción, está en el repositorio y tiene su correspondiente identificación y revisión para guardar la trazabilidad de dicha solicitud.

14

3

METODOLOGÍA DE DESARROLLO

3.1 Metodología de Gestión de Proyecto

Las metodologías de gestión de proyectos tienen como objetivo presentar un conjunto de técnicas tradicionales y modernas de modelado de sistemas que permitan desarrollar un software de calidad. Lo cual nos hace preguntarnos qué tipo de metodología debo utilizar para realizar mi solución informática.

Hoy en día entre la comunidad informática se está teniendo un debate abierto entre los partidarios de las metodologías tradicionales y aquellos que apoyan las metodologías agiles.

Por un lado, para muchos equipos de desarrollo el uso de metodologías tradicionales les resulta muy lejano a su forma de trabajo actual; considerando las dificultades de su introducción e inversión asociada en términos de formación y compra de herramientas. Por otro,

las

características de los proyectos para los cuales las metodologías ágiles han sido especialmente pensadas se ajustan a un amplio rango de proyectos; aquellos en los cuales los equipos de desarrollo son pequeños, con plazos reducidos, requisitos volátiles, basados en nuevas tecnologías (Orjuela Duarte & Rojas C, 2008).

De acuerdo a la información mostrada en la Tabla1 se puede observar la diferencia entre estas 2 metodologías y además conceptualizar que las metodologías de desarrollo ágil son más orientadas a procesos de gestión de proyectos de pocas semanas y con bajos niveles de formalización en la documentación requerida.

15

Metodologías Agiles

Metodologías Tradicionales

Basadas en heurísticas provenientes de

Basadas en normas provenientes de

prácticas de producción de código.

estándares seguidos por el entorno de desarrollo.

Preparados para cambios durante el

Cierta resistencia a los cambios.

proyecto. Reglas de trabajo impuestas internamente

Reglas de trabajo impuestas externamente.

(por el equipo). Proceso menos controlado, con pocos

Proceso mucho más controlado, con

principios.

numerosas políticas/normas.

Flexibilidad en los contratos debido a la

Existe un contrato prefijado.

respuesta a cambios. Grupos pequeños (