1.5.3. SERVIDORES WEB.

Los servicios web son esenciales en las Infraestructuras de Datos Espaciales (IDE)
porque permiten a los usuarios el acceder a datos de manera estándar mediante
Sistemas de Información Geográfica y otras aplicaciones a través de Internet. Debido a
que este tipo de servicios sirven como protocolo entre las aplicaciones cliente y nuestro
servidor de mapas, no pueden ser utilizados directamente en un navegador como
Microsoft Internet Explorer, Mozilla Firefox o Google Chrome.

Además de HTML, el desarrollo de nuevos lenguajes como XML ha hecho posible la

utilización de estándares que permiten que las aplicaciones descritas en distintos
lenguajes de programación y ejecutadas en distintas plataformas puedan interoperar
entre ellas, es decir, puedan intercambiar los datos.
De esta forma, los distintos servicios que se ofrecen en la Word Wide Web pueden
combinarse para ejecutar operaciones complejas.

La interoperabilidad puede ser de tres tipos:

Técnica: capacidad para que los sistemas de información intercambien señales y se
realiza tanto a través de una conexión física (cable, ondas, etc.), como por medio de
una serie de protocolos de comunicaciones (TCP/IP, etc.).
Sintáctica: capacidad para que un sistema pueda leer e interpretar los datos de otros
sistemas. Para ello se utilizan una serie de aplicaciones como las Interfaz de
programación de aplicaciones que permiten intercambiar y analizar los datos.
Semántica: capacidad de intercambiar el contenido de la información basándose en el
significado.
Estos servicios proporcionan mecanismos de comunicación estándares entre diferentes
aplicaciones, que interactúan entre sí para presentar información dinámica al usuario.
Para proporcionar interoperabilidad y extensibilidad entre estas aplicaciones, y que al
mismo tiempo sea posible su combinación para realizar operaciones complejas, es
necesaria una arquitectura de referencia estándar.
La estructura interna de un servicio web se basa en los siguientes protocolos y normas:
 SOAP (Simple Object Access Protocol): establece la forma en que dos

objetos en diferentes procesos pueden comunicarse mediante el intercambio de

datos en lenguaje XML.
 UDDI (Universal Description, Discovery and Integration): lista los servicios
web y los pone a disposición de los usuarios.
  WDSL (Web Services Description Language): permite que los servicios web
describan cómo deben ser tratados por otras aplicaciones.

1.5.4. OTROS.

Modelo cliente-servidor: Es el modelo más utilizado para realizar aplicaciones

distribuidas. Existe un proceso servidor y uno o varios procesos clientes. Este modelo
se utiliza en muchos servicios de Internet como HTTP, FTP, DNS... Este concepto
también puede aplicarse a los ordenadores servidor o cliente, cuyo nombre se debe a
que la ejecución de la mayoría de sus procesos son de tipo servidor o de tipo cliente.

Peer-to-peer: En el modelo cliente-servidor hay una clara diferenciación. El servidor

ofrece a los clientes servicios y los clientes utilizan estos servicios. En sistemas P2P los
procesos que participan en la comunicación realizan los mimos papeles: de cliente y de
servidor. Este sistema está más asociado a lo que es la informática distribuida, ya que
se olvida de la centralización y tiene un sistema más dinámico y descentralizado.

Cluster: es un conjunto de ordenadores conectados por una red de alta velocidad

(Gigabit Ethernet, Myrineto InfiniBand). Los computadores individuales pueden ser PC
convencionales que se instalan en un rack. Todos los ordenadores trabajan como un
único recurso de computación, mostrándose como un único sistema. En un cluster
todos los ordenadores comparten los discos y los distintos ordenadores que lo forman
están continuamente monitorizando para detectar posibles fallos de hardware. Si se
detecta un fallo, se planifica el trabajo del nodo erróneo en otro ordenador, de forma
que el usuario no percibe la parada del servicio. Los cluster se realizan mediante un
middleware que gestiona todo. Un cluster puede ser homogéneo (misma arquitectura,
SO...) o heterogéneo (distintos entornos, middlewares más complejos).

Grid: El concepto de grid, es similar al concepto de cluster. La principal diferencia con

un entorno cluster, es que en un entorno grid, los diferentes computadores del grid no
pertenecen a un mismo dominio de administración y por tanto están sujetos a
diferentes políticos de uso y de administración. La primera mención, y su definición
viene dada por Ian Foster: "Un sistema que coordina recursos, que no están sujetos a
un control centralizado usando interfaces y protocolos estándares, abiertos y de
propósito general para proveer de servicios relevantes".

1.5.4 Otros

Common Object Request Broker Architecture (CORBA) es un estándar definido

por Object Management Group (OMG) que permite que diversos componentes de
software escritos en múltiples lenguajes de programación y que corren en diferentes
computadoras, puedan trabajar juntos; es decir, facilita el desarrollo de aplicaciones
distribuidas en entornos heterogéneos.
Características

Entre las principales características de CORBA nos encontramos con:

 Independencia en el lenguaje de programación y sistema operativo: CORBA fue
diseñado para liberar a los ingenieros de las limitaciones en cuanto al diseño del
software. Actualmente
soporta Ada, C, C++, C++11, Lisp, Ruby, Smalltalk, Java, COBOL, PL/I y Python.
 Posibilidad de interacción entre diferentes tecnologías: uno de los principales
beneficios de la utilización de CORBA es la posibilidad de normalizar las interfaces
entre las diversas tecnologías y poder así combinarlas.
 Transparencia de distribución: ni cliente ni servidor necesitan saber si la aplicación
está distribuida o centralizada, pues el sistema se ocupa de todo eso.
 Transparencia de localización: el cliente no necesita saber donde ejecuta el servicio
y el servicio no necesita saber donde ejecuta el cliente.
 Integración de software existente: se amortiza la inversión previa reutilizando el
software con el que se trabaja, incluso con sistemas heredados.
 Activación de objetos: los objetos remotos no tienen por qué estar en memoria
permanentemente, y se hace de manera invisible para el cliente.
 Otras como: el fuerte tipado de datos, la alta capacidad de configuración, libertad de
elección los detalles de transferencia de datos, o la compresión de los datos.

Elementos

La arquitectura CORBA está orientada a objetos. En CORBA los objetos poseen

muchas de las características de otros sistemas orientados a objetos, como son la
herencia en cuanto a interfaces y el polimorfismo. Pero lo más interesante de este
aspecto, es la posibilidad de proporcionar estas características a lenguajes no
orientados a objeto como C o COBOL, aunque CORBA trabaja más eficientemente con
lenguajes orientados a objeto como son Java o C++.
Object Request Broker (ORB)
El Object Request Broker (ORB), es un componente fundamental de la arquitectura
CORBA y su misión es facilitar la comunicación entre objetos. Éste se encarga de
enviar las peticiones a los objetos y retornar las respuestas a los clientes que las
invocan por el proceso de serialización.
El ORB tiene como principal característica la transparencia. Facilita la comunicación
entre cliente y servidor ocultando:
 La localización de los objetos: El cliente no tiene porque saber donde se encuentra
el objeto destino, puede estar en su propia máquina o en un proceso en una
máquina remota.
 La implementación de los objetos: El cliente ignora el lenguaje de programación con
el que se ha escrito el objeto remoto, su implementación o el sistema operativo en
el que se encuentra.
 Estado de ejecución del objeto: Al enviar una petición sobre un objeto remoto,
el ORB se encarga de inicializar el objeto en caso de ser necesario, antes de
enviarle la petición.
 Mecanismos de comunicación de los objetos: El cliente no sabe qué mecanismos
de comunicación utiliza el ORB para enviar las peticiones y retornar el resultado.
Interface Definition Language (IDL)
El lenguaje de definición de interfaz o IDL (Interface Definition Language), es un
lenguaje que se utiliza para definir las interfaces entre los componentes de una
aplicación y es el elemento que soporta la interoperabilidad de la tecnología.
El IDL sólo puede definir interfaces, no implementaciones. Al especificar las interfaces
entre objetos en CORBA, IDL es el encargado de asegurar la independencia del
lenguaje de programación utilizado.
Para que esto sea posible, es necesario asegurar que los datos son correctamente
intercambiados entre dos lenguajes distintos, para lo cual IDL define los tipos de datos
de una forma independiente del lenguaje con las correspondencias necesarias. Por
ejemplo, un tipo long en C++ de 32 bits puede corresponderse con
un int de Java. OMG ha definido bastantes correspondencias con lenguajes de
programación populares, como: C, C++, COBOL, Java, Smalltalk o Ada.
Tendremos principalmente dos tipos diferentes de IDL en CORBA:
 Stub IDL: es la interfaz estática a los servicios declarados en las interfaces IDL,
para el cliente todas las llamadas parecen locales. Actuará como proxy del objeto
remoto, realizando la invocación de métodos remotos, incluyendo la serialización, la
recepción de respuestas y la deserialización. El cliente puede tener tantos stubs
 como interfaces IDL existan. Es generado a partir del IDL en el lenguaje de
programación del cliente (C, C++ Java, Smalltalk, Ada,… ) por un compilador IDL.
 Skeleton IDL: es el representante estático del cliente en el servidor. Para el servidor
todas las llamadas parecen locales. Es generado a partir del IDL por un
compilador IDL y realiza ladeserialización de las invocaciones del cliente.
Objetos por referencia
La referencia de los objetos se obtiene a través de un campo Uniform Resource
Identifier (URI) en formato cadena, una búsqueda NameServer (similar a la del Sistema
de Nombres de Dominio(DNS)) o pasada como argumento durante la llamada a
un método.
Los objetos referenciados son objetos mucho más livianos que implementan la interfaz
del objeto real, ya sea remoto o local. Las llamadas a métodos por referencia consisten
en una sucesión de llamadas al ORB que se encarga de bloquear los hilos y esperar
por una respuesta, ya sea de éxito o fracaso. Los parámetros, información de retorno
(en caso de haberla), y las excepciones son serializadas por el ORB internamente
según el lenguaje de programación y sistema operativo.
Datos por valor
El IDL proporciona el lenguaje de definición de intercomunicación entre objetos o
sistemas operativos. Los objetos de CORBA se pasan por referencia, mientras que los
datos (integers, doubles,structs, enums, etc...) se pasan por valor. Esta combinación
hace que podamos complementar datos fuertemente tipados al compilar clientes y
servidores, y aun así preservar la flexibilidad que CORBA nos facilita.
Objects by value (OBV)
Además de objetos remotos, CORBA y RMI-IIOP definen el concepto de Objects by
value u OBV (Objetos por valor) y Valuetypes. El código de los métodos de
objetos Valuetype es ejecutado localmente por defecto. Si el OBV ha sido recibido por
el lado remoto, el código necesario debe ser conocido a priori por ambas partes o
descargado dinámicamente por el emisor. Para hacer que todo esto sea posible, el
registro, definido en el OBV, contiene la base de código que contiene una lista,
separada en diferentes máquinas, de URLs desde donde este código debe ser
descargado. Además el OBV puede tener métodos remotos.
Los OBVs pueden tener campos que se transfieren cuando los OBVs son transferidos.
Estos campos pueden ser los OBVs por sí mismos, formando listas, árboles o gráficos
arbitrarios. Los OBVs poseen una jerarquía de clases, incluyendo herencia múltiple y
clases abstractas.
CORBA Component Model (CCM)
CORBA Component Model o CCM (Modelo de Componentes de CORBA) es un
añadido a la familia de definiciones de CORBA. Fue introducido en la versión CORBA 3
y describe un frameworkpara los componentes de CORBA. Aunque no depende de
language dependent Enterprise Java Beans (EJB) es una forma más general de éste,
proporcionando cuatro tipos diferentes de componentes en vez de los dos que
el EJB define. Además proporciona la abstracción de entidades que pueden proveer y
aceptar servicios a través de unas interfaces propias bien definidas llamadas ports
(puertos).

INTRODUCCION.

La arquitectura cliente-servidor define una relación entre el usuario de una estación de

trabajo (el cliente frontal) y un servidor posterior de archivos, impresión,
comunicaciones o fax, u otro tipo de sistema proveedor de servicios.

El cliente debe ser un sistema inteligente con su propia capacidad de procesamiento

para descargar en parte al sistema posterior (ésta es la base del modelo cliente-
servidor). Esta relación consiste en una secuencia de llamadas seguidas de
respuestas. Situar servicios de archivos (u otro tipo de servicios) en sistemas
posteriores dedicados tiene muchas ventajas. Es más sencillo realizar el mantenimiento
y la seguridad de unos servidores situados en un mismo lugar, y más simple el proceso
de realización de copias de seguridad, siempre que los datos se encuentren en una
única ubicación y una misma autoridad los gestione.