UC3 - Tecnologías 1

Computación Ubicua e
Inteligencia Ambiental
Sesión 4: Aplicaciones y
tecnologías de C.U. (1/2)
Prof. Robinson Rivas-Suárez
Universidad Central de Venezuela /
Universidad Internacional de Valencia
Algunas ideas
●
Hay múltiples modelos de software que se pueden
implementar para la C.U.
●
Se deben considerar muchos elementos: tiempo de
respuesta, seguridad, privacidad
●
El rol de los estándares es vital
●
Para la Computación Ubicua, el modelo de arquitectura de
software está íntimamente relacionado con el hardware
(hay cosas que desaprender ;-)
2
Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez
Créditos
Las imágenes de estas láminas han sido tomadas básicamente
de:
●
“Ubiquitous Computing: Smart Devices, Environments and
Interactions” Stefan Poslad, 2009 John Wiley & Sons, Ltd.
ISBN: 978-0-470-03560-3
●
Pervasive Computing and Networking, First Edition. Edited
by Mohammad S. Obaidat, Mieso Denko, and Isaac
Woungang, 2011 John Wiley & Sons, Ltd. Published 2011 by
John Wiley & Sons, Ltd. ISBN: 978-0-470-74772-8
●
Wikipedia.org
Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 3

Modelos de Arquitectura
●
Existen diferentes maneras como el software
interactúa con los humanos y con otros softwares. En
el caso de la Computación Ubicua, además, hay
diferentes niveles en que se capturan datos, se
procesan y se deciden acciones
●
Algunos de los niveles están cerca del usuario. Otros,
se procesan a nivel de middleware.
●
En casi todos los casos, algún procesamiento se realiza
en computadoras centralizadas, usualmente distantes
del usuario

Ejemplo cercano
Tiene Ud en su casa el asistente “Alexa” u otro similar. Lo tiene
integrado a un sensor de iluminación y a su smart-TV
https://jwautomations.com/

¿Cómo funcionan?
Podemos plantear las siguientes preguntas:
●
¿Todos los equipos deben ser del mismo fabricante?
●
¿Cómo interactúa “Alexa” con otros dispositivos?
●
¿Deben comunicarse permanentemente los dispositivos entre sí?
¿Cómo se hace eso?
Desde el punto de vista del programador:
●
¿Qué modelo de software se está usando?
●
¿Dónde se ejecutan los programas?
●
¿Quién es el “responsable” de la operación de este sistema?

Arquitecturas
Hay múltiples formas en que pueden interactuar estos

dispositivos. En adelante veremos conceptos como:
●
Middleware
●
Arquitectura Orientada a Servicios
●
Ciclos de vida de Servicios
●
Publicación, Descubrimiento e Invocación de Servicios
●
Composición y Orquestación de Servicios
●
Modelos P2P, RPC, Mesh

Smart Devices
Smart Services iHCI with Devices

Mobile Devices
Service Provision Life-cycle Operating

Architectures Systems
Discovery Interaction Composition

Abstraction VM
BIOS
Network
MTOS
Virtualisation Service Device Interoperability
Partitioning &
Viewpoints Distribution Orchestration
Resource
Choreography
Multi-Tier Volatile
Client
Server Types
Data
Caches RPC
Proxy Processing
P2P Read Ahead EDA Shared Repository

Middleware ESB
Grid Delayed Writes MOM
SOC
Poslad: Ubiquitous computing: smart devices, environments and interaction
Aspectos a tomar en cuenta
Los dispositivos “inteligentes” y “ubicuos” tienen
características híbridas entre los sensores pasivos (por ejemplo
termómetros) y dispositivos de cómputo más complejos, como
terminales
●
Muchos son multi-propósito, con componentes genéricos (por
ejemplo cámaras o sensores de sonido)
●
Muchos tienen un alto grado de personalización, son
“customizables”
●
Los dispositivos en general integran la interfaz de
captura de datos, cómputo y respuesta en
una sola unidad

Termómetro de acuario con WiFi9
Aspectos a tomar en cuenta
●
Con frecuencia deben operar en entornos móviles, lo que
significa que deben resolver ciertas premisas de
comunicaciones y control:
– Interactuar con servicios disponibles de fuentes
deconocidas
– Resolver de forma dinámica aspectos de seguridad y
autenticación
– Resolver la falta de acceso a servicios en cualquier punto
de su operación
– Operar con protocolos stateless tanto como con protocolos
statefull

Arquitecturas de Sistemas Distribuidos
La interacción de los dispositivos “inteligentes” con otros
elementos de cómputo, se convierte muy rápidamente en un
ecosistema con diversidad de hardware y software.
Google Assitant architectural example.

https://programmaticponderings.com/tag/google-assistant/
●
Siguiendo el ejemplo de “Alexa”, las interacciones pueden
involucrar rápidamente acceso a servicios web, a
infraestructuras de comunicaciones, y con certeza a
comunicaciones con centros de datos de las empresas
●
Modelar todos los elementos tecnológicos es una labor
compleja, sobre todo cuando hay diferentes puntos de vista

●
La ISO, la ITU y el IEEE han propuesto una serie de estándares
para facilitar la interoperabilidad y la definición de los
servicios y patrones de los sistemas distribuidos
IEEE
ITU-T
Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez ISO 13

Modelado de Sistemas Distribuidos
Específicamente, el framework RM-ODP de la ITU proporciona
cinco puntos de vista genéricos y complementarios sobre un
sistema y su entorno:
– Empresarial: Propósito, alcance y políticas del sistema. Describe los

requisitos comerciales y cómo cumplirlos.
– Información: Semántica de la información y su procesamiento.
Describe la estructura y tipo de los contenidos.
– Cómputo: Descomposición funcional del sistema en objetos que
interactúan a través de interfaces.
– Ingeniería: Mecanismos y funciones necesarios para soportar
comunicaciones distribuidas entre objetos en el sistema.
– Tecnología: Describe las tecnologías necesarias para proporcionar el
procesamiento, la funcionalidad y la presentación de la información.
Ejemplos de puntos de vista

¿Cómo simplificar lo complejo?
●
No hay “recetas” para modularizar. Muchos sistemas que en el
pasado eran considerados “modulares” hoy se consideran
monolíticos. Muchas soluciones modulares se centralizaron
nuevamente por eficiencia.
●
Meyer (1998) propuso una serie de guías para
simplificar y descomponer sistemas complejos en
componentes útiles. Estos principios sirven
(con sus matices) tanto para hardware como
para software

Principios de Meyer:
– Descomposición Modular: cada elemento (de Sw y Hw) debe ser

lo más independiente posible
– Composición Modular: Los elementos deben poder combinarse
con una semántica precisa
– Comprensibilidad Modular: Los módulos deben ser legibles y con
sentido práctico
– Continuidad Modular: Los módulos deben ser resistentes a
cambios en las especificaciones.
– Protección Modular: Cambios o errores en los módulos no deben
afectar al resto

●
En el mundo actual, esta tendencia lleva a la definición de:
– Estándares
– Regulaciones
– Protocolos
– API's
– Modelos de arquitectura
– Patrones
– Componentes reusables
– Servicios y microservicios

Ejemplo de abstracción modular
Web Browser
Access
Database File Applications e.g., Text Processing

Applications Processing, Email, etc
SQL Commands
DBMS
Data as records in files
File Manager
Data as pages (minimum Resource
chunk of data on disk) Management
Disk Manager
Data as parts of magnetic
disk tracks and sectors
Information System Resources

¿Cómo interactúan los componentes?
●
La modularidad y el uso de estándares y APIs exige un concepto
inherente a la modularidad: la transparencia
●
En esencia, debe procurarse (aunque normalmente es imposible
garantizar):
– Transparencia en el acceso: mediante protocolos correctos que no dependan
de las implementaciones
– Transparencia en la migración: En ambientes móviles, el cambio de localidad o
de proveedor de servicio no debe afectar la operación
– Transparencia a la escala: El aumento o reducción de la cantidad de
componentes no debe alterar el funcionamiento del sistema
– Transparencia en la concurrencia: diversas invocaciones de un servicio o
dispositivo deben ser independientes y comportarse correctamente
– Tolerante a Fallas: en diversos niveles, los potenciales problemas deben tener
respuesta adecuada sin alterar el sistema en su conjunto

¿Cómo interactúan los componentes?
●
Los sistemas modernos, además, deben considerar
aspectos que se nos ha enseñado a obviar por la
abstracciones a nivel de software:
– Uso de la memoria
– Uso de la batería
– Velocidad de acceso a la red
– Tamaño de los mensajes
– Swap time entre memoria principal y secundaria

Situación de ejemplo
●
En el popular juego “Pokemon Go”, imagine los aspectos
de diseño, al tener la idea original
– ¿Qué elementos colocaría en un servidor?

– ¿En la aplicación?
– ¿En la caché de los jugadores?
– ¿Qué consideraciones a nivel de conectividad tomaría?
– ¿Qué consideraciones a nivel de software?

El Modelo Cliente/Servidor
●
El modelo C/S se ha mantenido vigente por varias décadas,
debido a su versatilidad y beneficios.
●
Actualmente ha tenido evoluciones que lo adaptan a nuevos
modelos de hardware y Sistemas Operativos
●
Su principal ventaja es la abstracción del cómputo, que se
delega a un tercero en tanto el cliente espera respuesta

El Modelo Cliente/Servidor
●
Hay varias formas de implemetarlo
A I P
C
Monolithic
A I P
2 1
C C
Thin Client Servers
A P P
C 2 1 C
Fat Client Servers
Ubiquitous computing: smart devices, environments and interaction

Modelo Cliente/Servidor
●
¿De qué depende el tipo de Cliente o Servidor?¿Qué lleva a una
forma u otra de diseño?
●
Se deben considerar:
– Velocidad, capacidad, costo de la red
– Hardware local
– Disponibilidad y costo del servicio
– Seguridad/Privacidad de la aplicación
●
Aunque el servidor se considere único, puede haber diferentes
instancias en diferentes condiciones. Igual los clientes
●
Cuando todo reposa en el servidor, hay consideraciones de
eficiencia y seguridad

●
Si se colocan muchos recursos del lado del cliente, la
heterogeneidad de los mismos puede ser un problema. Aunque
en términos generales los equipos son más poderosos, puede
haber diferencias notorias en desempeño
–
●
Por el contrario, un cliente muy ligero
es fácil de controlar, pero presiona
el desempeño.
Dos versiones de una misma aplicación C/S

●
Dependiendo del grado de Cómputo, Datos, Comunicaciones e
Interfaces que tengan las diferentes partes del modelo, y de
cuántos elementos lo conformen, se dan diversas variantes
●
En la tecnología actual, no hay un solo modo de Cliente y
Servidor. Con frecuencia, el clientes hace las veces de servidor
y viceversa
●
Dependiendo de los componentes podemos tener:
– 1-capa, sistema monolitico
– 2-capas, cliente ligero
– 2-capas, cliente pesado
– Sistemas multi capa (3 en adelante), con clientes ligeros o pesados

Ejemplos de arquitecturas posibles
A I P A I P A P P
2 1
C C C C 2 1 C
Monolithic Thin Client Servers Fat Client Servers
A P I A P I P I
3 2
C 4 1 C 3 2
C C 6 1 C C C
5 4
Client Application Data Thin Client Application Bank Content

Ejemplos de sistema online
Customer Interaction Merchant Interaction
Purchase Catalogue Sales Accounts Inventory Delivery Bank

1. Query
2. Select
3. SubmitPO Check/
update
Confirm In stock
4. AckPO
DeliveryReq
5. SubmitADN
Delivery Arranged
6. SubmitInvoice
7. TransferFundsReq
8. AckTransferFunds

Más modularidad
●
Internamente, los componentes de Datos, Información,
Procesamiento y Comunicaciones pueden ser subdivididos
tantas veces como sea necesario.
●
Por ejemplo, el renglón “almacenamiento” usualmente
significa el acceso a nuevas capas de servicios, a Bases de
Datos Distribuidas, a accesos a Cómputo o Almacenamiento en
la Nube, etc.

Más modularidad
●
“Módulo” de almacenamiento
Access1
Access1(A) Access2
(A) Access2(A)
(A)
Transactions
Transactions Transactions
Transactions
Monitor:
Monitor:Route,
Route, Jobs
Jobs
schedule, monitor
schedule, monitor PP
Transaction
TransactionManager:
Manager:
record Lock
record lock,check-
lock, check- Lock
RR Logs
point, log
point, log Logs
Database
Database11
Rules
Rules

Más modularidad
●
“Módulo” de almacenamiento
Access1 (A)
Access1 Access
Accessnn(A)
Access1(A)
Access2 (A)
Access1 (A)
Transactions
Access2 (A)
Transactions (A) (A)
Transactions Transactions
Monitor: Route,
Monitor: Route,
schedule, monitor
Jobs
Jobs
Data
Datamining
mining(P)
(P) OLAP
OLAP(P)
(P)
schedule, monitor P
P
Transaction Manager:
Transaction Manager:
record lock, check- Lock
Lock Aggregated Metadata
Metadata
record lock, check-
point, log R Logs
R Logs
Aggregated repository
point, log
Data
Data repository
RR
Database 1
Database 1
Rules
Rules
Refresh,
Refresh, Load
Load,,Clean,
Clean, Transform
Transform
Export
Export Export
Export
RR RR
Database
Database11 Database
Database11

Procesamiento Distribuido
Es una de los elementos más complejos para distribuir. Las
decisiones involucran hardware, comunicaciones y correctitud
– En términos básicos, pareciera simplemente distribuir el
cómputo entre múltiples equipos
– Sin embargo, a mayor distribución, también se incrementan los
requerimientos de control y coordinación
Google Data Center, South Carolina

Procesamiento Distribuido
Modelos de cómputo distribuido:
– Supercomputadores
– Clusters
– Arquitecturas multi-core
– Arquitecturas P2P
– Cloud Computing
– Kubernetes
Cada modelo requiere un aprendizaje de herramientas, y
un desaprender constante

¿Cómo acceder a los servicios?
Por muchas razones, en general no conviene que los clientes
accedan directamente a los servicios. Entre otras:
– Seguridad
– Eficiencia
– Cuellos de botella en comunicaciones
El concepto de Proxy es útil para facilitar el intercambio de

datos de forma correcta

Acceso a servicios basado en Proxys
Algunas ventajas de este modelo:
– Facilitan el tema de la autenticación

– Adelantan pasos sin consumir ancho de banda
– Permiten una mayor heterogeneidad en las aplicaciones
cliente
– Ocultan al cliente el acceso a servicios dinámicos
– Resuelven problemas de comunicación o intermintencia
de red, incluyendo la implementación de cachés

Acceso a servicios basado en Proxys
Ob jec t5 Obje c t6
Objec t5 Ob jec t6
Ob jec t4
Objec t4
Objec t1 Ob jec t2
Encode / decode data for Ob jec t1 Ob je c t2
Ob jec t3
transmission
Objec t3
Client Proxy Server

User Query
Result
Optional confirmation
of result received
Por ejemplo, el módulo de comunicaciones de Android resuelve

temas de encriptación y retransmisión a nombre del usuario
Pregunta “Ingenua”
Ob jec t5 Obje c t6
Objec t5 Ob jec t6
Ob jec t4
Objec t4
Objec t1 Ob jec t2
Encode / decode data for Ob jec t1 Ob je c t2
Ob jec t3
transmission
Objec t3
Client Proxy Server

User Query
Result
Optional confirmation
of result received
¿Dónde se ejecuta el Proxy?¿Quién lo controla?

Middleware
Es una serie de softwares que, como su nombre lo indica, se
ejecuta “en medio” de otros. Esos “otros” son, usualmente, las
aplicaciones de los usuarios y el Sistema Operativo. Incluso,
interactúan con otros Middlewares
Ofrecen una serie de endpoints para servicios específicos, por

ejemplo
– Abrir sesión
– Enviar paquetes de datos

– Recibir respuestas
– Configurar opciones

Ejemplo de Middleware
Ciertos softwares complejos requieren acceso desde
middlewares para permitir una mayor interoperabilidad.
Wordpress es un ejemplo exitoso. SAP también se basa en este
modelo
Ejemplo de middlewares para acceso a SalesForce
¿Cómo usaría esto en SU PROYECTO de Computación Ubicua?

Reflexión
No basta una buena idea o un dispositivo ingenioso. Para que la
C.U. realmente facilite la vida de las personas y oculte las
complejidades de la tecnología, debe diseñarse de forma
cuidadosa el software
O, mejor dicho, los softwares invloucrados
En general, la tendencia es a simplificar las interacciones entre

componentes. Pero simplificar un componente puede significar
dificultar otro
La evolución de la teconología ha decantado el concepto de

servicios y microservicios
Arquitecturas y Computación Orientadas a
Servicios (SOA)
Esta tendencia del software permite diseños donde los
componentes:
1 Son autónomos e independientes

2 Son (o deben ser) autocontenidos
3 Pueden estar en ubicaciones dinámicas
4 Pueden estar implementados en diferentes plataformas
5 Pueden pertenecer a distintas organizaciones o empresas
6 Pueden tener distintas políticas de acceso y costos

Niveles de las Arquitecturas Orientadas a Servicios
(SOA)
Se han propuesto diferentes niveles de abstracción para la SOA
https://www.researchgate.net/publication/228743117_ESB-Modern_SOA_Infrastructure

Estándares de SOA
Hay una serie de estándares que se han convertido en clave

para potenciar la interoperabilidad
– (XML) Web Services

– SOAP
– REST
– Computer Grids OGSI
– OASIS SOA RM
– Open Group SOA Working Group
– Semantic Web. OWL

Flexibilidad del modelo
No todos los servicios requieren una infraestructura de software

compleja
Con frecuencia los mismos dispositivos clientes tienen

capacidades de servidor, mediante implementaciones ligeras
Muchos dispositivos se comunican entre sí de forma dinámica,

estableciendo comunicaciones directas entre ellos

Sistemas Peer to Peer (punto a punto - P2P)
Funcionan como sistemas ágiles y dinámicos
●
Nodos interconectados, sin control centralizado
●
La topología es dinámica
●
En general, se usa para compartir recursos (especialmente
ancho de banda o archivos digitales)
●
Debe resolver fallas de comunicaciones
●
No puede depender de un estado de red
●
Hay topologías híbridas

Un ejemplo agradable

Un ejemplo polémico

Tipos de redes P2P
No son sencillos los retos de infraestructura, seguridad y
coordinación. Hay tres tipos de redes P2P
Puras
– Parciales
– Híbridas
¿Qué premisas deben resolverse prioritariamente?
– Registrar participantes
– Ubicar contenido
– Lidiar con las fallas
– Resolver duplicidades

Tipos de redes P2P
search
A B Link not
accessed
H
G
Servent
Node C D E F Pure
N P2P Hybrid
J
New P2P
search Node I L
Centralised K Node
Directory with
Node (used in content
Hybrid P2P
for searches)

Tipos de redes P2P
Super
H
Node G
C D E F
Node Partial
N with P2P
J content
I L
K

Redes P2P
Las redes P2P “pasaron de moda” luego que las principales
epxeriencias P2P cayeron en desuso por asuntos legales
Sin embargo, ha habido un “renacer” del concepto, gracias a

las interacciones sociales y a los dispositivos domésticos
interconectados
Un tema clave en los nuevos modelos, es la detección

automática de los servicios, la especificación de los datos a
compartir, la privacidad y la seguridad
Todo esto con dispositivos de muy bajas prestaciones

Conectividad del hogar
La cercanía del dispositivo es clave. Protocolos ligeros como
Bluetooth y ZigBee son fundamentales

Conectividad del hogar
En 2021, se anunció un nuevo protocolo unificado, con el apoyo
de grandes consorcios del área. Se llama Matter
https://www.xatakahome.com/domotica/

Reflexiones
●
El concepto de Computación Ubicua tiene varias caras:
●
Interfaces innovadoras e Implícitas
●
Comodidad
●
Solución de problemas reales
●
Pero, para que las mismas se puedan implementar, debe
diseñarse y decidirse con qué herramientas se construirá
la solución
●
De este diseño dependerán muchos aspectos operativos
●
Muchas (muchas) soluciones geniales han fallado por una
implementación inadecuada
Reflexiones
El diseño es importante pero las herramientas también:
●
¿Tiene el dispositivo las capacidades que le estamos
exigiendo?
●
¿Se requiere un software adicional de base?
●
¿La red de comunicación es eficiente y segura?
●
¿Cuántas operaciones quedan en cada lado de la
solución?
●
¿Puede funcionar sin conectividad total/parcial?

Fin de la Primera Parte de
Tecnologías

MIL GRACIAS POR LA ATENCIÓN
Prof. Robinson RIVAS-SUÁREZ

Director, Computer Science School
Universidad Central de Venezuela
robinsonsamuel.rivas@viu.es
robinson.rivas@ciens.ucv.ve

UC3 - Tecnologías 1

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

UC3 - Tecnologías 1

Cargado por

Copyright:

Formatos disponibles

Computación Ubicua e

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 3

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 4

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 5

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 6

Hay múltiples formas en que pueden interactuar estos

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 7

Smart Services iHCI with Devices

Service Provision Life-cycle Operating

Discovery Interaction Composition

P2P Read Ahead EDA Shared Repository

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 10

Google Assitant architectural example.

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 12

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez ISO 13

– Empresarial: Propósito, alcance y políticas del sistema. Describe los

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 15

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 16

– Descomposición Modular: cada elemento (de Sw y Hw) debe ser

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 17

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 18

Database File Applications e.g., Text Processing

Information System Resources

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 19

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 20

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 21

– ¿Qué elementos colocaría en un servidor?

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 22

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 23

Ubiquitous computing: smart devices, environments and interaction

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 25

Dos versiones de una misma aplicación C/S

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 27

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 28

Purchase Catalogue Sales Accounts Inventory Delivery Bank

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 29

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 30

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 31

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 32

Google Data Center, South Carolina

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 34

El concepto de Proxy es útil para facilitar el intercambio de

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 35

– Facilitan el tema de la autenticación

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 36

Client Proxy Server

Por ejemplo, el módulo de comunicaciones de Android resuelve

Client Proxy Server

¿Dónde se ejecuta el Proxy?¿Quién lo controla?

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 38

Ofrecen una serie de endpoints para servicios específicos, por

– Enviar paquetes de datos

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 39

Ejemplo de middlewares para acceso a SalesForce

¿Cómo usaría esto en SU PROYECTO de Computación Ubicua?

O, mejor dicho, los softwares invloucrados

En general, la tendencia es a simplificar las interacciones entre

La evolución de la teconología ha decantado el concepto de

1 Son autónomos e independientes

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 42

Computación Ubicua. Universidad Internacional de Valencia. Robinson Rivas Suárez 43

Hay una serie de estándares que se han convertido en clave

– (XML) Web Services