259730295 unidad-1-contexto-de-la-programacion-cliente-servidor

ISMAEL ALDANA FERNANDEZ 1
INSTITUTO TECNOLOGICO DE ORIZABA
INSTITUTO TECNOLÓGICO DE ORIZABA
ING. INFORMÁTICA
PROGRAMACION EN AMBIENTE CLIENTE-SERVIDOR
Hora: 13 a 14
PRESENTA:
ALDANA FERNANDEZ ISMAEL
No. DE CONTROL:
11010383
PROFESOR:
PELAEZ CAMARENA SILVESTRE GUSTAVO
INVESTIGACION UNIDAD 1
Contexto de la programación cliente-servidor

Contenido
Introducción ............................................................................................................................. 3
Desarrollo................................................................................................................................. 3
1.1. Arquitectura cliente/servidor............................................................................................... 3
Elementos de la arquitectura cliente/servidor......................................................................... 4
El servidor ......................................................................................................................... 5
El cliente............................................................................................................................ 5
El Middleware.................................................................................................................... 5
El funcionamiento básico....................................................................................................... 6
1.2 Modelos de dos y tres capas................................................................................................. 7
Arquitectura en 2 niveles ....................................................................................................... 7
Arquitectura en 3 niveles ....................................................................................................... 7
Comparación entre ambos tipos de arquitecturas.................................................................... 8
1.3 Usos y Aplicaciones.............................................................................................................. 8
1.4 Comunicación entre programas............................................................................................ 9
1.5. Modelos de computación distribuida..................................................................................11
1.5.1. RMI ................................................................................................................................11
La arquitectura RMI puede verse como un modelo de cuatro capas.........................................12
Primera capa ....................................................................................................................12
Segunda capa....................................................................................................................12
Tercera capa.....................................................................................................................12
Cuarta Capa......................................................................................................................12
1.5.2. COM/DCOM....................................................................................................................13
La arquitectura DCOM ..........................................................................................................13
1.5.3. Servicios Web. ................................................................................................................14
La interoperabilidad puede ser de 3 tipos:.............................................................................15
1.5.4. Otros..............................................................................................................................16
Conclusión...............................................................................................................................17
Referencias..............................................................................................................................17

Introducción
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 capacidadde 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.
Desarrollo
1.1. Arquitectura cliente/servidor
La arquitectura cliente/servidor persigue el objetivo de procesar la información de un modo
distribuido.De estaforma,losusuariosfinales puedenestardispersosenunáreageográficamás o
menos extensa (un edificio,una localidad,un país,…) y acceder a un conjunto común de recursos
compartidos.
Además,el accesodebesertransparente(elclientepuededesconocerlaubicaciónfísicadel recurso
que pretende utilizar) y, preferiblemente, multiplataforma, es decir, independiente del sistema
operativo, del software de aplicación e incluso del hardware.
En definitiva, cuando hablamos de la implantación de una arquitectura cliente/servidor, nos
referimos a un sistema de información distribuido.

Además de la transparencia y laindependencia del hardware y del software, una implantación
cliente/servidor debe tener las siguientes características:
o Debe utilizarprotocolos asimétricos, donde el servidor se limita a escuchar, en espera de
que un cliente inicie una solicitud.
o El servidorofrecerárecursos,tantológicoscomofísicosaunacantidadvariable ydiversade
clientes (por ejemplo, espacio de almacenamiento, bases de datos, impresoras, etc.)
o El servidorofrecerátambiénunaserie de servicios,que seránusadosporlosclientes.Estos
serviciosestarán encapsulados,paraocultaralosclienteslosdetallesdesuimplementación
(por ejemplo,aceptarel requerimientode uncliente sobre unabase de datos o formatear
los datos obtenidos antes de transmitirlos al cliente).
o Se facilitará la integridad y el mantenimientotanto de los datos como de los programas
debido a que se encuentran centralizados en el servidor o servidores.
o Los sistemas estarán débilmente acoplados, ya que interactúan mediante el envío de
mensajes.
o Se facilitará la escalabilidad, de manera que sea fácil añadir nuevos clientes a la
infraestructura(escalabilidadhorizontal) oaumentarla potenciadel servidoroservidores,
aumentando su número o su capacidad de cálculo (escalabilidad vertical)
Elementos de la arquitectura cliente/servidor.
De lo dicho hasta ahora, podemos deducir que los principales elementos que conforman la
arquitectura cliente/servidor son los siguientes:

El servidor
Cuando hablamos de una forma genérica, si mencionamos a un servidor, nos referimos a un
ordenador, normalmente con prestaciones elevadas, que ejecuta servicios para atender las
demandas de diferentes clientes.
Sin embargo, bajo el punto de vista de la arquitectura cliente/servidor, un servidor es un proceso
queofreceelrecurso (o recursos) queadministraa losclientesquelo solicitan (consultarladefinición
de cliente más abajo).
Es muy frecuente que, para referirse a un proceso servidor, se utilice el término back-end.
Segúnel tipode servidorimplantado,tendremosuntipode arquitecturacliente/servidordiferente.
Por último,mencionarque enalgunas ocasiones,unservidorpuede actuar,a su vez,como cliente
de otro servidor.
El cliente
Igual que antes, al hablar de forma genérica sobre un cliente, nos referimos a un ordenador,
normalmente con prestaciones ajustadas, que requiere los servicios de un equipo servidor.
Sinembargo,bajoel puntode vistade laarquitecturacliente/servidor,un clienteesunprocesoque
solicita los servicios de otro, normalmente a petición de un usuario.
En entornos cliente/servidor, suele utilizarse el término front-endpara referirse a un proceso
cliente.
Normalmente, un proceso cliente se encarga de interactuar con el usuario, por lo que estará
construidocon algunaherramientaque permitaimplementarinterfacesgráficas(GUI).Además,se
encargaráde formularlassolicitudesal servidoryrecibirsurespuesta,porloquedeberáencargarse
de una parte de la lógica de la aplicación y de realizar algunas validaciones de forma local.
El Middleware
Es la partedel softwaredel sistema quese encarga del transportede los mensajesentreel cliente y
el servidor, por lo que se ejecuta en ambos lados de la estructura.
El middleware permite independizara los clientes y a los servidores, sobre todo, gracias a
los sistemas abiertos, que eliminan la necesidad de supeditarse a tecnologías propietarias.
Por lo tanto, el middleware facilita el desarrollo de aplicaciones, porque resuelve la parte del
transporte de mensajesyfacilitalainterconexiónde sistemasheterogéneossinutilizartecnologías
propietarias.
Además, ofrece más control sobre el negocio, debido a que permite obtener información desde
diferentesorígenes(uniendotecnologíasyarquitecturasdistintas)yofrecerlade maneraconjunta.
Podemos estructurar el middleware en tres niveles:
o El protocolo de transporte, que será común para otras aplicaciones del sistema.

o El sistema operativo de red
o El protocolo del servicio, que será específico del tipo de sistema cliente/servidor que
estemos considerando.
El funcionamiento básico
Aunque es probable que a estas alturas ya te hagas una idea sobre el funcionamientogeneral del
modelo cliente/servidor, vamos a concretarlo a continuación:
1. Lo primero que debe ocurrir es que se inicie el servidor. Esto ocurrirá durante el arranque
del sistemaoperativooconlaintervenciónposteriordeladministradordel sistema.Cuando
termine de iniciarse, esperará de forma pasiva las solicitudes de los clientes.
2. En algún momento, uno de los clientes conectados al sistema realizará una solicitud al
servidor.
3. El servidorrecibelasolicituddelcliente,realizacualquierverificaciónnecesariay,si todoes
correcto, la procesa.
4. Cuando el servidor disponga del resultado solicitado, lo envía al cliente.
5. Finalmente, el cliente recibe el resultado que solicitó. A continuación realiza las
comprobacionesoportunas(sisonnecesarias) y,si eraese el objetivofinal,se lomuestraal
usuario.
Si descomponemos este modo de funcionamiento en elementos estructurales, será más fácil
comprender los conceptos implicados. De esta forma, podemos obtener una definición de la
arquitectura por niveles, estructurada como sigue:
o Un nivel de presentación, que aglutina los elementos relativos al cliente.
o Un nivel de aplicación, compuesto por elementos relacionados con el servidor.

o Un nivel de comunicación, que está formado por los elementos que hacen posible la
comunicación entre el cliente y el servidor.
o Un nivel de base dedatos,formadoporloselementosrelacionadosconel accesoalosdatos.
1.2 Modelos de dos y tres capas
Arquitectura en 2 niveles
La arquitectura en 2 niveles se utiliza para describir los sistemas cliente/servidor en
donde el cliente solicita recursos y el servidor responde directamente a la solicitud,
con sus propios recursos. Esto significa que el servidor no requiere otra aplicación
para proporcionar parte del servicio.
Arquitectura en 3 niveles
En la arquitectura en 3 niveles, existe un nivel intermediario. Esto significa que la
arquitectura generalmente está compartida por:
1. Un cliente, es decir, el equipo que solicita los recursos, equipado con una
interfaz de usuario (generalmente un navegador Web) para la presentación
2. El servidor de aplicaciones (también denominado software intermedio),
cuya tarea es proporcionar los recursos solicitados, pero que requiere de otro
servidor para hacerlo
3. El servidor de datos, que proporciona al servidor de aplicaciones los datos
que requiere

Comparación entre ambos tipos de arquitecturas
La arquitectura en 2 niveles es, por lo tanto, una arquitectura cliente/servidor en la
que el servidor es polivalente, es decir, puede responder directamente a todas las
solicitudes de recursos del cliente.
Sin embargo, en la arquitectura en 3 niveles, las aplicaciones al nivel del servidor
son descentralizadas de uno a otro, es decir, cada servidor se especializa en una
determinada tarea, (por ejemplo: servidor web/servidor de bases de datos). La
arquitectura en 3 niveles permite:
 Un mayor grado de flexibilidad
 Mayor seguridad, ya que la seguridad se puede definir independientemente para
cada servicio y en cada nivel
 Mejor rendimiento, ya que las tareas se comparten entre servidores
1.3 Usos y Aplicaciones
Cuando la operaciónentre clientes y servidores se realiza a través de una red (como
es el caso de Internet), la información viaja codificada a lo largo de redes que
pueden ser del tamaño de un edificio o de tamaño planetario. En caso de redes
grandes, aparte de servidores y clientes, se necesita un tercer tipo de máquinas
para gestionar las transmisiones.

Se denominan enrutadores ("Routers"), y funcionan como elementos de recepción
y transmisión de tráfico Internet.
El paradigma cliente-servidor no solo se utiliza en referencia a las máquinas físicas,
también a los programas que las hacen funcionar según su utilidad. Por ejemplo,
son frecuentes expresiones tales como "cliente de correo" o "servidor de noticias"
en referencia a programas. La primera se refiere al que utilizamos normalmente
para interrogar nuestro buzón e-mail, "bajar" el correo y manipularlo (verlo,
imprimirlo, borrarlo, etc.). El segundo se refiere a un programa o sistema de ellos,
que en un servidor (máquina) realiza el trabajo de alojar los mensajes de noticias,
atender las peticiones de los "clientes", etc.
Observe que en realidad, el concepto cliente/servidor es muy genérico, y que puede
ser entendido incluso en el ámbito de una sola máquina, donde unas aplicaciones
pueden prestar servicio a otras. Sinembargo, su significado desde el punto de vista
informático suele presuponer la existencia de varias máquinas (al menos dos)
unidas en una red:
 Un servidor es cualquier máquina que dispone un recurso para ser
compartido.
 Un cliente es cualquier máquina que necesita un recurso externo.
Un servidor de determinado recurso puede ser cliente de otros y a la inversa. Un
cliente puede ser a su vez servidor de otro recurso.
1.4 Comunicación entre programas
El proceso para la creación de un servicio siempre comienza con la creación
del Socker. Así como el cliente necesita llamadas específicas en determinados
momentos, el servidor trabajo de modo similar pero añade unas pocas llamadas
extras al sistema. El servidor utiliza la llamada del sistema Socket, pero debe hacer
un trabajo extra que era opcional para el cliente, el cliente siempre realiza una
conexión activa porque la persigue enérgicamente los servidores por otro lado
necesitan proporcionar un numero de puesto especifico y consiste a los programas
clientes si les va a prestar servicio.

El programa servidor que escriba deberá utilizar las llamadas de sistema
socker (), bind (), listen (), accept (). Y mientras el programa cliente es una conexión
activa, el servidor es una conexión pasiva. Las llamadas del sistemas () y accept ()
crean una conexión solo cuando el cliente pide una conexión (similar a la acción de
responder al timbre de un teléfono.
El ejemplo de servidor escucha en un socket (puerto 8000) esperando peticiones
entrantes. Cualquier programa, como el cliente de ejemplo, puede conectar con este
servidor y pasarle hasta 16.384 bytes de datos.
El servidor trata los datos como datos ASCII y los convierte en mayúsculas antes
de pasárselos a! programa cliente. Estos dos sencillos programas se pueden volver
a utilizar fácilmente cuando se escriban programas cliente-servidor basados en
socket.
Los servidores que pueden recibir muchas peticiones simultáneas lo usan para crear
un proceso separado para la administración de peticiones de servicio
constitucionalmente caras. El servidor crea un socket permanente para la escucha
de peticiones de servicio; cuando un cliente conecta con el servidor, se crea un
socket temporal. Cada vez que un cliente conecta con un servidor, se abre un nuevo
socket temporal entre el cliente y el servidor.

1.5. Modelos de computación distribuida
La computación distribuida (o grid computing / network computing) es un modelo de
computación basado en el uso de recursos de una red de máquinas independientes
para el procesado de unidades discretas de datos a través de un protocolo común
cuyo objetivo es crear una potente red de procesado de datos que puede incluso
superar a los grandes superordenadores.
Estas redes de computación distribuida son mayoritariamente utilizadas para
investigaciones científicas que necesitan largos tiempos de procesado mediante
ordenadores
Un sistema distribuido está compuesto de nodos, posiblemente heterogéneos,
conectados mediante una red. Un sistema de esta clase puede utilizarse
efectivamente solo si el software es capaz de presentar al usuario el concepto de
single system image (SSI) sobre el sistema físicamente distribuido. De esta forma
todos los recursos de un nodo deberían poder accederse transparentemente desde
cualquier otro nodo.
1.5.1. RMI
RMI (Java Remote Method Invocation) es un mecanismo ofrecido por Java para
invocar un método de manera remota. Forma parte del entorno estándar de
ejecución de Java y proporciona un mecanismo simple para la comunicación de
servidores en aplicaciones distribuidas basadas exclusivamente en Java. Si se
requiere comunicación entre otras tecnologías debe utilizarse CORBA o SOAP en
lugar de RMI.
RMI se caracteriza por la facilidad de su uso en la programación por estar
específicamente diseñado para Java; proporciona paso de objetos por referencia
(no permitido por SOAP), recolección de basura distribuida y paso de tipos
arbitrarios (funcionalidad no provista por CORBA).
A través de RMI, un programa Java puede exportar un objeto, con lo que dicho
objeto estará accesible a través de la red y el programa permanece a la espera de
peticiones en un puerto TCP. A partir de ese momento, un cliente puede conectarse
e invocar los métodos proporcionados por el objeto.
La invocación se compone de los siguientes pasos:
 Encapsulado (marshalling) de los parámetros (utilizando la funcionalidad
de serialización de Java).

 Invocación del método (del cliente sobre el servidor). El invocador se queda
esperando una respuesta.
 Al terminar la ejecución, el servidor serializa el valor de retorno (si lo hay) y lo
envía al cliente.
 El código cliente recibe la respuesta y continúa como si la invocación hubiera
sido local.
La arquitectura RMI puede verse como un modelo de cuatro capas.
Primera capa
La primera capa es la de aplicación y se corresponde con la implementación real
de las aplicaciones cliente y servidor. Aquí tienen lugar las llamadas a alto nivel
para acceder y exportar objetos remotos. Cualquier aplicación que quiera que
sus métodos estén disponibles para su acceso por clientes remotos debe
declarar dichos métodos en una interfaz que extienda java.rmi.Remote.
Segunda capa
La capa 2 es la capa proxy, o capa stub-skeleton. Esta capa es la que interactúa
directamente con la capa de aplicación. Todas las llamadas a objetos remotos y
acciones junto con sus parámetros y retorno de objetos tienen lugar en esta
capa.
Tercera capa
La capa 3 es la de referencia remota, y es responsable del manejo de la parte
semántica de las invocaciones remotas. También es responsable de la gestión
de la replicación de objetos y realización de tareas específicas de la
implementación con los objetos remotos, como el establecimiento de las
persistencias semánticas y estrategias adecuadas para la recuperación de
conexiones perdidas. En esta capa se espera una conexión de tipo stream desde
la capa de transporte.
Cuarta Capa
La capa 4 es la de transporte. Es la responsable de realizar las conexiones
necesarias y manejo del transporte de los datos de una máquina a otra. El
protocolo de transporte subyacente para RMI es JRMP (Java Remote Method
Protocol), que solamente es "comprendido" por programas Java.

1.5.2. COM/DCOM.
Microsoft Distributed COM (DCOM) extiende COM (Component Object Model) para
soportar comunicación entre objetos en ordenadores distintos, en una LAN, WAN, o incluso
en Internet. Con DCOM una aplicación puede ser distribuida en lugares que dan más
sentido al cliente y a la aplicación.
Como DCOMes una evolución lógica de COM, se pueden utilizar los componentes creados
en aplicaciones basadas en COM, y trasladarlas a entornos distribuidos. DCOM maneja
detalles muy bajos de protocolos de red, por lo que uno se puede centrar en la realidad de
los negocios: proporcionar soluciones a clientes.
La arquitectura DCOM
DCOM es una extensión de COM, y éste define como los componentes y sus
clientes interactúan entre sí. Esta interacción es definida de tal manera que el cliente
y el componente pueden conectar sin la necesidad de un sistema intermedio. El
cliente llama a los métodos del componente sin tener que preocuparse de niveles
más complejos.
La Figura 1 ilustra esto en la notación de COM
En los actuales sistemas operativos, los procesos están separados unos de otros.
Un cliente que necesita comunicarse con un componente en otro proceso no puede
llamarlo directamente, y tendrá que utilizar alguna forma de comunicación entre
procesos que proporcione el sistema operativo. COM proporciona este tipo de
comunicación de una forma transparente: intercepta las llamadas del cliente y las
reenvía al componente que está en otro proceso.
La Figura 2 ilustra como las librerías de COM/DCOM proporcionan la forma de
comunicar el cliente y el componente:

Cuando el cliente y el componente residen en distintas máquinas, DCOM
simplemente reemplaza la comunicación entre procesos locales por un protocolo de
red. Ni el cliente ni el componente se enteran de que la unión que los conecta es
ahora un poco más grande.
La Figura 3 representa la arquitectura DCOM en su conjunto: Las librería de COM
proporcionan servicios orientados a objetos a los clientes y componentes, y utilizan
RPC y un proveedor de seguridad para generar paquetes de red estándar que
entienda el protocolo estándar de DCOM.
1.5.3. Servicios 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 3 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".

Conclusión
Una arquitectura es un entramado de componentes funcionales que aprovechando
diferentes estándares, convenciones, reglas y procesos, permite integrar una amplia
gama de productos y servicios informáticos, de manera que pueden ser utilizados
eficazmente dentro de la organización.
Referencias
Loger,A. (s.f.). Desarrollo deaplicacionesweb.Obtenidode
http://alog78503.blogspot.mx/2013/02/121-aplicaciones-de-23-y-n-capas_25.html
Vignaga,A.(s.f.). Universidad dela República,Facultad de Ingeniería.Obtenidode
http://moodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/LP/AM/01/Arquitecturas_y_tecnolo
gias_para_el_desarrollo_de_aplicaciones_web.pdf

259730295 unidad-1-contexto-de-la-programacion-cliente-servidor

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a 259730295 unidad-1-contexto-de-la-programacion-cliente-servidor

Similar a 259730295 unidad-1-contexto-de-la-programacion-cliente-servidor (20)

Último

Último (20)

259730295 unidad-1-contexto-de-la-programacion-cliente-servidor