Web Service SOAP

API CSS HTML MySQL PHP Prolog Proyecto SOAP

Especificaciones

Año: 2016
Categoría: Servicio Web
Interfaz Gráfica: Sí
Lenguajes: PHP, Prolog, HTML, CSS, JS
Fragmentación: Sí
SGBD: MySQL

Enlaces

Código fuente en Github.
Archivo .exe de este proyecto.

Introducción

El crecimiento que vive la web hoy en día, trae consigo el incremento de servicios que se pueden disponer al público para realizar operaciones que se adaptan mejor a sus necesidades. Los usuarios que consumen y generan información lo hacen a través de buscadores web que permiten referenciar recursos o simplemente visualizar páginas web que a su vez les ofrezcan recursos de interés. Entendiendo a dichos buscadores web como clientes que necesitan comunicarse con servidores para obtener recursos, dando a lugar a una interacción cliente servidor.

Los servicios web, proveen una infraestructura para mantener una rica y mas estructurada forma de interoperabilidad entre clientes y servidores, proveyendo unabase por la cual un cliente que puede estar en un localización, pueda interactuar con un servidor en otra localización sin necesidad de supervisión humana, siendo a su vez una colección de operaciones que pueden ser usados y están al alcance de cualquier cliente sobre todo el Internet [Coulouris and Dollimore and Kindberg and Blair (2012)].

Entre las publicaciones relacionadas con el objeto de estudio presentado, nos encontramos con [Navarro (2007)], que indica que el uso de SOAP es adecuado cuando se estable un contrato para la descripción de la interfaz que el servicio ofrece así como también que la arquitectura de los servicios web deben abordar requerimientos no funcionales y especificaciones como las transacciones y operaciones de recuperación e inserción de datos de en una base de datos, haciendo uso de una metodología descriptiva y comparativa.

También se encuentra a [Bermúdez e Ibáñez y González (2004)], los cuales utilizan un modelo de programación evolutiva y concluyen en su trabajo de estudio sobre la seguridad en servicios basados en XML, donde en una arquitectura cliente/servidor, el cliente debe ser capaz de realizar peticiones encriptados para luego el servidor, desencriptarlas y procesar las operaciones.

Objetivos

Objetivo General

Desarrollar servicios web en Prolog para el sistema de fotocopiado de la Universidad Nacional Experimental de Guayana con la utilización de SOAP y su descripción de servicio WSDL.

Objetivos específicos

Análisis de los requerimientos funcionales y de información de los servicios a ofrecer.
Diseñar diagramas, modelos y arquitectura de los servicios a proponer.
Desarrollar servicios web sobre operaciones del sistema de fotocopiado de la Universidad Nacional Experimental de Guayana.
Realizar pruebas de los resultados obtenidos del desarrollo de los servicios web.
Implementar los servicios web desarrollados en el laboratorio de Sistemas Distribuidos de la Universidad Nacional Experimental de Guayana.

Metodología de Desarrollo

Para el desarrollo del presente proyecto, se hizo uso de la metodología en Cascada para desarrollo de software, la cual posee 5 fases de desarrollo durante el proceso que conlleve a la realización del mismo, las cuales se desarrollan de forma lineal o secuencial, y es imprescindible que se tengan los requerimientos bien claros y definidos [Nava (2006)]. Las fases de este modelo se presentan a continuación:

Análisis de requerimientos: Se debe realizar un análisis tanto de los requerimientos funcionales como de informaciones necesarias y requeridas para las operaciones y funciones que ha de cumplir el sistema a desarrollar.
Diseño: Realizar los diseños de los diagramas pertinentes que para el desarrollo del sistema así como también el diseño de la arquitectura en la que se basaran los servicios web, siendo este el paso anterior a la parte de codificación, por lo tantoresulta necesario tener a disposición todos los diagramas y modelos en que estará basado el sistema.
Codificación: Fase donde se inicia el desarrollo del sistema propuesta en base a los requerimientos ya establecidos en conjunto con el diseño del mismo que permita tener como base plasmada el funcionamiento que ha de tener el sistema.
Pruebas: Donde se verifica que el comportamiento del sistema desarrollado cumple con los requerimientos establecidos con anterioridad en las fases iniciales, cumpliendo con el modelado para el sistema, de modo que sirve como comparación de calidad para establecer el funcionamiento de las operaciones que ha de cumplir el sistema.
Implementación: Una vez desarrollado el sistema y luego de haberle realizado las pruebas pertinentes, este ha de ser implementado en el lugar donde sea requerido, para ser usado por los usuarios finales destinado a darle provecho a las funcionalidades establecidas y alcanzadas.

El siguiente informe sigue una estructura en la cual en la sección 2 se tratara sobre los materiales y métodos utilizados para el desarrollo propuesto, en la cual se detalla la arquitectura del sistema denotando los distintos servicios que se ofrecen, así como se tratan temas sobre el modelo de interacción del sistema así como del modelo de fallas que este presenta para el tratamiento de irregularidades que se puedan presentar, en conjunto con la instalación y pruebas realizadas del sistema. Se continúa en la sección 3, referente a los resultados obtenidos del desarrollo de los servicios del sistema fotocopiado para luego, dar lugar a la sección 4, donde se indican las conclusiones de los objetivos logrados.

Materiales y métodos

Análisis de requerimientos

Para poder aplicar y consumir un servicio web, es requerido hacer uso del protocolo SOAP, que es un protocolo ligero basado en XML y está diseñado para el intercambio de información en un ambiente de computación distribuido y no existe un concepto de servidor central, ya que todos los nodos pueden ser considerados iguales [Englender (2002)].

Al estar basado en XML, se define el mismo como lenguaje jerárquico basado en etiquetas, que permite describir contenido que es específico a nuestras propias aplicaciones en una manera estándar, y el protocolo SOAP, a través del XML, es transportado a con HTTP. [Englender (2002)].

El servicio se consume en conjunto con un servidor el cual recibirá las peticiones por parte de los clientes. Este servidor ha de ser en Prolog, el cual se conectara con otros servidores que contendrán la base de datos fragmentada en modo de distribuida, la cual a su vez es una colección de múltiples bases de datos lógicamente interrelacionados sobre una red de computadoras [Hernández (2013)].

Para evitar los problemas de interoperabilidad de servicios basados en SOAP, siendo interoperabilidad como la habilidad de dos sistemas para intercambiar información y utilizarla, contamos con WSDL, de Web Services Definition Languaje, o en español, Lenguaje de definición de servicios web, el cual proporciona un lenguaje estructurado para describir un servicio, su locación, los métodos del servicios, parámetros, tipos de datos y más. [Englender (2002)].

Finalmente, el servicio a suministrar, debe ser un conjunto de servicios o métodos que permitan realizar operaciones sobre el sistema de fotocopiado de la UNEG, de manera que permita conocer el número de copias que ha sacado, buscar estudiantes, registrar estudiantes y mostrar factura luego de efectuar la operación de sacar copias, utilizando los mecanismos antes mencionados. Por lo tanto, los requerimientos del sistema como tal son:

Requerimientos funcionales:
- Servicio Web con servidor Prolog que permita realizar distintas operaciones.
- Utilización de SOAP para el intercambio de información y peticiones, basado en XML.
- Utilización de WSDL, para describir la estructura de un servicio, sus métodos y sus tipos de datos como de parámetros.
- Base De datos distribuidos.
Requerimientos de Información:
- Manejar información sobre datos de los estudiantes.
- Manejar cantidad de copias que un estudiante que le quedan.

Diseño

Para el desarrollo del servicio, hacemos uso de una Base de Datos relacional, con tres entidades que son:

Estudiante: Entidad principal, que brindara la información sobre los estudiantes para poder consumir las fotocopias. Sus atributos son:
- Cedula
- Nombre
- Apellido
- Copias
- Clave
- Sede
Fotocopia: Entidad que permite saber el número de copias y la fecha en que se sacaron las copias y sirve para realizar la factura de la transacción. Sus atributos son:
- Id_fotocopias
- Copias
- Fecha
Pendiente: Entidad destinada a cubrir una de las fallas cuando se caiga el servidor secundario de base de datos. Sus atributos son:
- Id_pendiente
- Acción
- Cedula
- Nombre
- Apellido
- Copias
- Clave
- Sede

Teniendo en cuenta estas entidades y sus atributos, se obtiene el Diagrama de Entidad/Relación del cual se tienen las siguientes relaciones:

Un estudiante, genera de [0,N] Copias.
1 Fotocopia es sacada Solo por [1] Estudiante.
1 Fotocopia genera de [0,1] Pendiente
1 Pendiente es generada solo por [1] Estudiante.

El diseño de la codificación, está basada en el Modelo Vista Controlador (MVC), el cual separa la codificación por su interés. Por un lado, se tiene toda la programación del modelo de negocios, por otro lado están las vistas que serán vistos por los usuarios y por el otro, los controladores de cada vista. En total, el diseño de la programación se dividirá en:

Modelos: Todos los programas y códigos destinados al manejo del modelo de negocio del sistema.
Vistas: Todo lo visual para el usuario, en donde se mostraran los resultados proporcionados por el servicio.
Controladores: Todos los programas encargados de controlar las vistas, de manera que sirven para controlar los resultados obtenidos por los modelos y proporcionárselos a las vistas.

Arquitectura del sistema

Se tiene una arquitectura Cliente/Servidor, de manera que un servidor pueda proporcionar servicio a los clientes. Este cliente, esta dado por Google Chrome, a través de una página HTML con JavaScript para la noción dinámica de la página. Estos clientes, realizaran peticiones a un servidor a través de un método POST del protocolo HTTP con AJAX.

Este servidor que ha recibido dicha petición, debe tomar la petición y enviar una petición SOAP al servidor Principal, y si se busca un estudiante y este pertenece a la base de datos de dicho servidor, es decir de la Sede Atlántico, este servidor principal (PHP), enviara un SOAP OUT, o mensaje SOAP de salida al servidor Prolog, y este se encargara de enviar un objeto AJAX al cliente. En caso de que el estudiante no pertenezca a la Sede Atlantico, el servidor principal ha de comunicarse con sql con el servidor Prolog que es el que posee las fragmentaciones de la Sede Upata, y este buscara el estudiante en su base de datos, y luego envía sql al servidor principal de vuelta, y este, envía el SOAP OUT, o SOAP de salida, y este servidor en PROLOG se encargara de proporcionar el objeto AJAX en respuesta para el cliente.

Por lo tanto, entendemos que la comunicación sql entre ambos servidores llega a ser opcional, y además se deduce que la fragmentación es por Relación, ya que un estudiante pertenecerá al fragmento que contenga una base de datos, según su sede.

La arquitectura requiere poseer dos servidores para la base de datos fragmentada, de modo que se tenga una fragmentación en un servidor y el resto de la fragmentación, se localice en el servidor que resta. La comunicación entre servidores, puede verse como si el servidor de Prolog, es decir el servidor destinado a la Sede UPATA, pasa a ser un cliente del Servidor PHP, en caso de que un estudiante no pertenezca a dicha sede UPATA, por lo tanto este servidor PROLOG deberá pedir información al Servidor PHP de Atlántico.

El uso de un servidor en PHP es para manejar las peticiones SOAP, ya que el servidor PROLOG, por sí solo, solo puede enviar peticiones SOAP, mas no puede mantenerse activo escuchando peticiones SOAP, es decir, para que un servidor PROLOG pueda recibir un mensaje SOAP, es que este sea una respuesta a una petición que el mismo había hecho.

Ya sabiendo la comunicación entre los servidores, el intercambio de mensajes se realiza sobre XML puesto que es en lo que está basado SOAP. El servidor en PROLOG, procesara el XML, para mandar como respuesta al cliente un objeto AJAX, ya que el cliente envía su petición a través de POST sobre AJAX.

Modelo de Fallas

Para el comportamiento de fallas que pueda ocasionar irregularidades en el sistema, tenemos dos enfoques.

TCP

Como las consultas a Base de Datos están sobre TCP, y esto se logra a través de la librería que proporciona PHP para trabajar con bases de datos mySQL, por lo tanto, se asegura establecer una conexión entre puntos a punto a la hora de comunicación, y de esta manera siempre se tiene asegurado la recepción de los mensajes.

Caída de servidor de Base de Datos

En cada Computadora, hay dos servidores, un Servidor Web y un Servidor para Base de datos. Ya se dijo que, para que se pueda enviar una respuesta al cliente, se debe enviar un mensaje SOAP entre servidores, (Del servidor Prolog un SOAP IN, al servidor en PHP, y un SOAP OUT, del servidor PHP al servidor Prolog de vuelta), por lo tanto, si se cae el servidor de Base de datos deUPATA, no resulta de mayor problema ya que de igual manera se enviaran los SOAP, y el servicio de sacar copia se realiza en ATLANTICO. Como no se encuentra el estudiante en la base de datos de Upata, ya que el servidor de UPATA esta caído, lo importante sería que se dejara el estudiante igual pudiera sacar sus Fotocopias.

Por lo tanto, si el estudiante a buscar se encuentra en la base de datos que se cayó y esta es la base de datos de UPATA, nos encontraríamos con la situación de no poder actualizar los datos del estudiante, o consumir sus copias, lo que se hace es colocar al estudiante en una tabla PENDIENTE en la base de datos. En esta tabla, se agregaran los datos pertinentes del estudiante y las copias que saco, de manera que cuando el servidor de UPATA se restablezca, se puedan insertar los datos del estudiante de UPATA a la base de datos del servidor correspondiente a esa Sede.

Resumiendo:

Se consume el servicio de sacar copias en ATLANTICO.
Si ambos servidores web y de base de datos están activos, no hay problema.
Si se cae el servidor de Upata, y se intenta consumir el servicio con un estudiante que pertenece a la sede Upata, los datos del estudiante se guardaran en una tabla Pendiente, y se permitirá sacar sus copias.
Del punto anterior, cuando se restablezca el servidor de Upata, todos los registros de la Tabla Pendiente, se vaciaran en su respectiva base de datos de Upata, y se descontaran las copias que le queden.
En el caso de que el servidor de base de datos de atlántico se caiga, no
se podrá consumir el servicio.

Caída del servidor web cualquiera

En el caso de que algún servidor Web se caiga, tampoco se podrá consumir el servicio, ya que no se podrá realizar las transacciones de mensajes SOAP, por lo que caeríamos, al igual que los bancos, que si se cae el sistema principal, no cuentan con sistema global.

Instalación

Programas necesarios:

Apache
PHP
MySQL
Swi-Prolog
Chromium
Allow-Control-Allow-Origin (Extensión de Google Chrome)

Antes de comenzar la instalación vamos a definir nombres para cada una de las PC, ya que los paquetes a instalar y las configuraciones varían según la función que cumplirá cada PC, teniendo esto en cuenta llamaremos a la primera computadora PC1 (En esta PC se estará ejecutando el servidor en Prolog y estará la base de datos que simula una sede en Upata), la segunda computadora la llamaremos PC2 (En esta PC se estará ejecutando el servidor Apache y estará la base de datos que simula la sede principal en este caso atlántico), y por último la tercera computadora la llamaremos PC3 (Esta PC se usará como cliente para consumir los servicios). En cuanto a los archivos necesarios para la configuración y ejecución estarán dentro una carpeta llamada rootcs comprimida en un archivo .zip con el mismo nombre.

Instalación y configuración de paquetes en PC1

Swi-Prolog:

Para instalar este paquete ejecutamos desde la terminal como superusuario el siguiente comando:
# apt-get install swi-prolog
Añadir las librerías necesarias para trabajar con SOAP y WSDL, para ello nos dirigimos al directorio rootcs/libreriaspl/ y copiaremos los 3 archivos .pl contenidos aquí (soap.pl, wsdl.pl y xml_schema.pl ), estos archivos debemos pegarlos en el directorio /usr/lib/swi-prolog/library/

MySQL:

Para instalar este paquete ejecutamos desde la terminal como superusuario el siguiente comando:
# apt-get install mysql-server mysql-client
Durante la instalación procedemos a seguir los pasos de configuración que aparecerán en pantalla (Aquí definiremos entre otras cosas la contraseña para el usuario root).
Accedemos a la shell de MySQL como usuario como root y con la clave que especificamos en el paso anterior a través del siguiente comando:
# mysql -u root -p
Creamos un usuario para esta base de datos llamado uneg_upata y con la clave uneg_upata a través del siguiente comando:
mysql> CREATE USER uneg_upata IDENTIFIED BY 'uneg_upata';
Otorgamos los privilegios de conexión y administración al usuario recién creado sobre la base de datos llamada uneg_upata (Aún no creada) a través del siguiente comando:
mysql> GRANT ALL ON uneg_upata.* TO 'uneg_upata'@'%';
Creamos una base de datos llamada uneg_upata a través del siguiente comando:
mysql> CREATE DATABASE uneg_upata;
Importamos la base de datos ubicada en rootcs/bbdd/uneg_upata.sql a través del siguiente comando:
# mysql -u root -p uneg_upata < rootcs/bbdd/uneg_upata.sql
Configuramos MySQL para permitir conexiones remotas desde cualquier host, para ello vamos a abrir el archivo /etc/mysql/my.cnf y buscaremos las siguientes líneas y las descomentamos en caso de estar comentadas:
- skip-external-locking
- bind-address = 127.0.0.1
  Cambiaremos 127.0.0.1 por 0.0.0.0 de tal manera que en el archivo my.cnf quede así:
- bind-address = 0.0.0.0
Podemos abrir y editar el archivo my.cnf a través del siguiente comando:
# gedit /etc/mysql/my.cnf
Reiniciamos el servicio mysql a través del siguiente comando:
# service mysql restart

Instalación y configuración de paquetes en PC2

Apache:

Para instalar este paquete ejecutamos desde la terminal como superusuario el siguiente comando:
# apt-get install apache2

PHP:

Para instalar este paquete ejecutamos desde la terminal como superusuario el siguiente comando:
# apt-get install php5 libapache2-mod-php5 php5-mcryp

MySQL:

Para instalar este paquete ejecutamos desde la terminal como superusuario el siguiente comando:
# apt-get install mysql-server php5-mysql
Durante la instalación procedemos a seguir los pasos de configuración que aparecerán en pantalla (Aquí definiremos entre otras cosas la contraseña para el usuario root).
Accedemos a la shell de MySQL como usuario como root y con la clave que especificamos en el paso anterior a través del siguiente comando:
# mysql -u root -p
Creamos un usuario para esta base de datos llamado uneg y con la clave uneg a través del siguiente comando:
mysql> CREATE USER uneg IDENTIFIED BY 'uneg';
Otorgamos los privilegios de conexión y administración al usuario recién creado sobre la base de datos llamada uneg_upata (Aún no creada) a través del siguiente comando:
mysql> GRANT ALL ON uneg.* TO 'uneg'@'%';
Creamos una base de datos llamada uneg_upata a través del siguiente comando:
mysql> CREATE DATABASE uneg;
Importamos la base de datos ubicada en rootcs/bbdd/uneg.sql a través del siguiente comando:
# mysql -u root -p uneg < rootcs/bbdd/uneg.sql
Configuramos MySQL para permitir conexiones remotas desde cualquier host, para ello vamos a abrir el archivo /etc/mysql/my.cnf y buscaremos las siguientes líneas y las descomentamos en caso de estar comentadas:
- skip-external-locking
- bind-address = 127.0.0.1
  Cambiaremos 127.0.0.1 por 0.0.0.0 de tal manera que en el archivo my.cnf quede así:
- bind-address = 0.0.0.0
Podemos abrir y editar el archivo my.cnf a través del siguiente comando:
# gedit /etc/mysql/my.cnf
Reiniciamos el servidor mysql a través del siguiente comando:
# service mysql restart
(Opcional) Instalamos PHPMyAdmin ejecutando desde la terminal como superusuario el siguiente comando:
# apt-get install phpmyadmin
Durante la instalación procedemos a seguir los pasos de configuración que aparecerán en pantalla teniendo en cuanta lo siguiente:
- Seleccionaremos apache2, cuando se nos pregunte por el servidor web en el que queremos ejecutar Phpmyadmin.
- Seleccionaremos Sí, cuando se nos pregunte si deseamos configurar la base de datos para phpmyadmin con <<dbcongfig-common>>.
- Introduciremos y confirmaremos la contraseña de administrador root de Mysql.
Incluimos phpmyadmin dentro de la configuración de apache, para ello vamos a abrir el archivo /etc/apache2/apache2.conf y nos vamos al final e introducimos el siguiente texto:
- # phpMyAdmin Configuración
- Include /etc/phpmyadmin/apache.conf
Podemos abrir y editar el archivo apache2.conf a través del siguiente comando:
# gedit /etc/apache2/apache2.conf
Reiniciamos el servidor apache a través del siguiente comando:
# service apache2 restart

Instalación y configuración de paquetes en PC3

Chromium:

Para instalar este paquete ejecutamos desde la terminal como superusuario el siguiente comando:
# apt-get install chromium
Instalamos la extensión de Google Chrome (también es compatible con chromium) llamada Allow-Control-Allow-Origin, para ello nos dirigimos a la url que se muestra a continuación y seleccionamos la opción añadir a chrome:
https://chrome.google.com/webstore/detail/allow-control-allow-origi/nlfbmbojpeacfghkpbjhddihlkkiljbi
Activamos esta extensión pulsando el icono llamado CORS y moviendo el
botón de enable a la derecha.

Una vez finalizada la instalación de todos los paquetes necesarios en todas las computadoras procedemos a copiar los siguientes archivos y carpetas que se encuentran dentro de la carpeta rootcs y los pegamos en /var/www/html/ tal como se especifica a continuación:

En la PC1 copiamos todos los archivos y carpetas contenidos en la carpeta rootcs a excepción de la carpeta prolog/ para ello nos ubicamos dentro de la carpeta rootcs y como superusuario ejecutamos los siguientes comandos:
# cp -r * /var/www/html/ # rm -r /var/www/html/prolog
En la PC2 copiamos solo la carpeta prolog/ para ello nos ubicamos dentro de la carpeta rootcs y como superusuario ejecutamos los siguientes comandos:
# cp -r prolog/ /var/www/html/

Configuración de archivos en PC1

WSDL: Vamos a modificar el archivo /var/www/html/controladores/uneg_servicios.php para que apunte al wsdl que contiene la descripción de los servicios prestados, para ello abrimos el archivo con el siguiente comando:
# gedit /var/www/html/controladores/uneg_servicios.php

Ahora reemplazamos localhost por la IP de la PC2 (Para ver la IP ejecute # ifconfig en la PC2) en la siguiente linea:
$server = new SoapServer('http://localhost/prolog/uneg.wsdl');

Si la IP de la PC2 es 192.168.0.101 entonces nos quedaría de la siguinte manera:
$server = new SoapServer('http://192.168.0.101/prolog/uneg.wsdl');
Base de Datos externa: Modificamos el archivo /var/www/html/config/dataBaseConfig2.php de tal forma que este apunte al servidor MySQL de la PC2, para ello abriremos el archivo ejecutando como superusuario el siguiente comando:
# gedit /var/www/html/config/dataBaseConfig2.php

Ahora le asignamos la IP de la PC2 a “hostname” (Para ver la IP ejecute # ifconfig en la PC2) en la siguiente linea:
"hostname" => "192.168.0.111",

Si la IP de la PC2 es 192.168.0.101 entonces nos quedaría de la siguinte manera:
"hostname" => "192.168.0.101",
Peticiones a la PC2 (Servidor Prolog): Ahora modificaremos cada uno de los archivos .js ubicados en /var/www/html/vistas/js/ para que realicen las peticiones al servidor prolog ubicado en la PC2, para ello abrimos cada uno de los archivos .js ejecutando como superusuario el siguiente comando:
# gedit /var/www/html/vistas/js/buscar_estudiante.js

Ahora reemplazamos localhost por la IP de la PC2 (Para ver la IP ejecute # ifconfig en la PC2) en la siguiente linea:
url: "http://localhost:3000/uneg",

Si la IP de la PC2 es 192.168.0.101 entonces nos quedaría de la siguinte manera:
url: "http://192.168.0.101:3000/uneg",

*Repetimos este proceso para cada uno de los archivos .js solo sebemos cambiar el nombre del archivo en el comando por ejemplo para el archivo llamado consumir_copias.js sería:
# gedit /var/www/html/vistas/js/consumir_copias.js

Configuración de archivos en PC2

Peticiones a la PC1 (Servidor Apache): Vamos a modificar el archivo /var/www/html/prolog/uneg.pl para que realice las llamadas SOAP a la PC1, para ello abrimos el archivo con el siguiente comando:
# gedit /var/www/html/prolog/uneg.pl

Ahora reemplazamos localhost por la IP de la PC1 (Para ver la IP ejecute # ifconfig en la PC1), podemos ayudarnos con el editor de texto para que busque y reemplace todas las palabras “localhost” y la reemplace por la IP de la PC1, para ello pulsamos CTRL+H e ingresamos la palabra a buscar que queremos reemplazar en este caso “localhost” y la palabra que la reemplazará en este caso la IP de la PC1.

Si la IP de la PC1 es 192.168.0.100 entonces nos quedarían todas las url de la siguinte manera:
'http://192.168.0.100'
WSDL: Modificamos el archivo /var/www/html/prolog/uneg.wsdl de tal forma que este apunte al archivo que gestiona las llamados SOAP llamado uneg_servicios.php ubicados en la PC1, para ello abriremos el archivo ejecutando como superusuario el siguiente comando:
# gedit /var/www/html/prolog/uneg.wsdl

Ahora reemplazamos localhost por la IP de la PC1 (Para ver la IP ejecute # ifconfig en la PC1), podemos ayudarnos con el editor de texto para que busque y reemplace todas las palabras“localhost” y la reemplace por la IP de la PC1, para ello pulsamos CTRL+H e ingresamos la palabra a buscar que queremos reemplazar en este caso “localhost” y la palabra que la reemplazará en este caso la IP de la PC1, tal como lo hicimos en el paso anterior.

* Para mayor información ver el Informe en los enlaces ya que este contiene capturas de pantallas que pueden facilitar la comprensión.

Conclusión

La Universidad Nacional Experimental de Guayana cuenta con un servicio de Fotocopiado, el cual cuenta con irregularidades que corresponder a problemas con la replicación, ya que un estudiante puede consumir fotocopias en una sede, y alguien con su misma cedula puede consumir copias del mismo estudiante en otra sede, ya que la replicación no es instantánea, por lo tanto resulta necesario una alternativa para resolver dicho problema, por lo que se desarrollo un servicio web en Prolog para el sistema de fotocopiado de la Universidad Nacional Experimental de Guayana con la utilización de SOAP y su descripción de servicio WSDL.

Como todo desarrollo de software, es necesario seguir una metodología que permita el desarrollo del proyecto bajo en un enfoque esquemático, por lo tanto:

Se tiene que el análisis de los requerimientos funcionales y de información de los servicios a ofrecer viene siendo el punto más importante del desarrollo del servicio a proponer, ya que de esta manera, se puede entender los problemas que el sistema existente pueda tener, y sus características de funcionamiento y poder detectar mejoras posibles que se pueden implementar.

Con los requerimientos una vez captados, esto nos permite poder diseñar los programas, diagramas y modelos que nos den un enfoque de cómo debería ser la arquitectura a utilizar en el sistema. Estos diseños son la base para la codificación, porque nos identifica el funcionamiento y la manera en que se debe manejar la información que se está procesando y consumiendo con los servicios.

Estos diseños, nos sirven como marco de trabajo para la codificación, entendiendo la manera en que debe funcionar los códigos que se han desarrollar las operaciones que el sistema ha de realizar. Estos modelos sirven también para verificar que lo que se está desarrollando es lo que en realidad se debe programar, y de esta manera, no sirve también para realizar las pruebas al sistema, ya que comose dijo, sirven para verificar que se está programando lo que se estableció en la fase de diseño, dando veracidad de esta manera a las pruebas realizadas.

Y ya con las pruebas realizadas, y entendiendo que están correctas, sin necesidad de volver a modificar mas nada, se puede implementar el servicio desarrollado para la Universidad Nacional Experimental de Guayana, como alternativa para contrarrestar las irregularidades que presenta el sistema actual.