Mejoras a la predictibilidad de la tecnología Java EE
1. Mejoras
a
la
predic.bilidad
de
la
tecnología
Java
EE
Pablo
Basanta-‐Val,
Marisol
García-‐Valls
mailto:pbasanta@it.uc3m.es
Universidad
Carlos
III
de
Madrid
h@p://www.it.uc3m.es/drequiem
2. Índice
• Contexto:
• Contribuciones:
– Requisitos
y
Niveles
de
Integración
– Arquitectura
para
Java
EE
de
Mempo
real
– Aplicación
Mpo
para
Java
EE
• Evidencias
empíricas
• Conclusiones
y
líneas
futuras
CEDI
2013
2
3. Contexto
• Actualmente
hay
una
revolución
con
la
computación
en
la
nube
(IaaS,
PaaS,
SaaS)
• Números
retos
dentro
de
la
computación
distribuida
• Desde
el
punto
de
vista
del
Mempo
real
la
computación
en
la
nube
• P.
ej.
Cómo
se
encajan
caracterísMcas
como
la
elasMcidad
y/o
algoritmos
de
Mempo
de
respuesta
CEDI-‐13
3
4. Contribución
• Explorar
mejoras
en
la
predicMbilidad
de
Java
EE
• Java
ya
está
“en
la
nube”
(ver
Heroku
y
Amazon
E2C)
• Java
EE
8
(2014)
prevé
transformar
Java
EE
en
una
plataforma
para
la
nube
• Java
EE
puede
ejecutarse
sobre
Java
de
Mempo
real
• Aproximación
via
Java
de
Mempo
real:
+
Hacer
uso
de
la
tecnología
Java
de
Mempo
real
ya
existente
(maquinas
virtuales,
especificaciones
como
RTSJ
o
DRTSJ,
…)
+
Modelos
de
planificación
y
otras
infraestructuras
similares
• Revisar
el
modelo
computacional
de
Java
EE
• Comunidad
Java
de
Mempo
real
podría
beneficiarse
de
esta
aproximación
• Sólo
algunos
trabajos
tratan
el
uso
de
contenedores
con
Java
de
Mempo
real
CEDI-‐13
4
5. Requisitos
1/2
• [REQ1]
Java
EE
debe
de
ser
predecible
localmente
en
cada
nodo
.
• [Dis.R1]
Abordable
mediante
una
máquina
virtual
de
Mempo
real.
• [REQ2]
Ofrecer
predic.bilidad
entre
diferentes
nodos
equipados
con
Java
de
Mempo
real.
• [Dis.R2]
Directo
mediante
DRTSJ
u
otras
vías
como
el
uso
de
servicios
web.
• [REQ3]
Suportar
múl.ples
aplicaciones
de
diferentes
usuarios
• [Dis.R3]
Soportable
mediante
aislamiento
(e.g.
Java
Isolates)
CEDI-‐13
5
6. Requisitos
(2/2)
• [Req4]
Dar
cabida
a
elementos
específicos
de
Java
EE
• [Dis.R4]
Hay
que
ver
cada
servicio
uno
a
uno
para
poder
decidir
sobre
su
relación
beneficio
coste
• [Req5]
Ser
no
disrupMvo
con
la
tecnología
Java
EE
ya
existente
• [Dis.
R5]
Ha
de
poder
soportar
componentes
que
no
sean
de
Mempo
real
• [ R e q 6 ]
O f r e c e r
c a p a c i d a d e s
d e
extensibilidad
para
el
futuro
• [Dis.
R6]
Puede
imitar
la
estrategia
descrita
por
Java
de
Mempo
real
CEDI-‐13
6
7. Niveles
de
integración
entre
Java
EE
y
Java
de
Mempo
real
• Nivel
0
– Acceso
a
tecnología
Java
de
Mempo
real
– Sencillo
de
implementar
– Suficiente
para
algunas
aplicaciones
• Nivel
1
– PredicMbilidad
dentro
del
contenedor
y
del
servidor
de
aplicaciones
– El
contenedor
decide
qué
servicios
están
disponible
• Nivel
2
– Hay
gestores
de
recursos
que
interoperan
en
un
conjunto
de
maquinas
Java
EE
de
Mempo
real
– Es
el
de
mayor
nivel
computacional,
pero
también
el
de
mayor
beneficio
tecnológico
CEDI-‐13
7
8. Arquitectura
para
Java
EE
de
Mempo
real
• Basada
en
capas
• Capas:
– Recursos
– Java
de
Mempo
real
– Java
EE
de
Mempo
real
• Nombramiento,
seguridad,
administración,
comunicaciones
y
transacciones
– Aplicaciones
basadas
en
componentes
Java
EE
•
(EJBs
de
sesion
y
de
enMdad)
CEDI-‐13
8
RTSJ, DRTSJ y/o SCJ
Java de
tiempo real
Java EE de
tiempo real
Aplicaciones
empresariales
de tiempo real
CPU Memoria Red
Nombramiento
(JNDI)
Seguridad
(JAAS)
Transacciones
(JTS)
Aplicación
Servlets EJBS Aplicacion
Comunicación
(RMI)
Admin
Recursos
9. Anotaciones
de
Mempo
real
para
Java
EE
Recurso
Anotaciones para
aplicaciones
Computación
@RT_Schedule_Params{
release
periodic
start
period
deadline
mit) }
Computación
@RT_Scheduling_Params{
Priority }
Memoria
@RT_Memory_Params{
allocationRate
ImmortalMemory
MaxMemory }
Computación
@RT_Processing_Group_Pa
rams{ release
periodic
start
period
deadline
mit)}
Memoria
@RT_Concurrent_model{
noheap=false }
• Java
EE
permite
definir
caracterísMcas
no
funcionales
–
ficheros
xml
– mediante
anotaciones
• Estos
dos
modelos
se
pueden
extender
con
caracterísMcas
de
Mempo
real
– Tres
recursos:
cpu,
memoria
y
red
(modelada
como
computación)
– Completo
para
uMlizar
teoría
clásica:
• C:
coste,
• T:
período,
• D:
plazo,
• P:
prioridad
– Otras
caracterísMcas
más
ligadas
a
Java
de
Mempo
real
(uso
de
NhRos
y
recolectores
de
basura
de
Mempo
real).
9
10. Ejemplo
de
aplicación
Mpo
• Acceso
a
la
información
de
un
servo
mediante
un
navegador
• Solución
con
el
modelo
propuesto
– Componente
web
– Componente
EJB
• Tres
prioridades:
– Servlet
a
prioridad
23
– EJB
de
acceso
a
25
CEDI-‐13
10
Aplicación
ServoBean
<prio 25>
AccessServ
<prio 23>
AccessServ
<prio 23>
Java EE
De tiempo real
Servo Servo
Bean
Internet
Access
Serv
Java de tiempo real
Prio=23Prio=25
Flujo de
aplicación
11. Código
de
la
aplicación
(½)
CEDI-‐13
11
01:public class Servo extends HttpServlet{
02: @EJB
03: private ServoBean servo;
04: @RT_Scheduling_Params(priority=23)
05: public void service (HttpServletRequest
06: req, HttpServletResponse resp)
07: throws ServletException, IOException {
08: resp.getWriter().
09: println(servo.updateServo());
10: }
11: }
Aplicación
ServoBean
<prio 25>
AccessServ
<prio 23>
AccessServ
<prio 23>
Java EE
De tiempo real
Servo Servo
Bean
Internet
Access
Serv
Java de tiempo real
Prio=23Prio=25
Flujo de
aplicación
• Inyección
de
dependencia
de
ServoBean
(03)
• Parámetros
de
Mempo
real
(04)
• Invocación
sobre
componente
remoto
(09)
12. Código
de
la
aplicación
(+½)
CEDI-‐13
12
Aplicación
ServoBean
<prio 25>
AccessServ
<prio 23>
AccessServ
<prio 23>
Java EE
De tiempo real
Servo Servo
Bean
Internet
Access
Serv
Java de tiempo real
Prio=23Prio=25
Flujo de
aplicación
• EJB
sin
estado
(mediante
anotación)
(01)
• Parámetros
de
Mempo
real
(03)
01: @Stateless
02: public class ServoBean {
03: @RT_Scheduling_Params(priority=25)
04: public String updateServo(){
05: return drequiem.servo.update();
06: }
07: }
13. Resultados
empíricos
• ObjeMvo:
Comprobar
las
relaciones
de
coste/beneficio
en
applicaciones
Java
EE
cuando
se
pasada
de
un
Java
tradicional
a
Java
de
Mempo
real
• Aplicación
de
carga:
– 1
servlet
– Un
1
ejb
que
realiza
unas
operaciones
parametrizables
por
el
usuario
(trabajo
0
a
5000)
CEDI-‐13
13
Java 1.5.0 Oracle JRT
Glassfish Glassfish
(a) tradicional (a) propuesto
Prueba
(trabajo 0, …,5000)
Prueba
(trabajo 0, …,5000)
14. Tendencias
• Aplicaciones
con
costes
inferiores
al
milisegundo
– Java
ofrece
mejores
Mempos
de
respuesta
(Java
es
más
rápido
que
Java
de
Mempo
real
• Por
encima
del
milisegundo
– Java
de
Mempo
real
va
mejor
(Java
de
Mempo
real
quita
interferencia)
CEDI-‐13
14
15. Relaciones
coste/beneficio
• Coste
máximo
de
Java
de
Mempo
real
– (24%)
• Beneficio
máximo
de
Java
de
Mempo
real
– (58%)
CEDI-‐13
15
16. Conclusiones
• Se
ha
puesto
en
evidencia
la
importancia
de
ofrecer
cierto
soporte
de
Mempo
real
en
la
nube
• Se
ha
mejorado
el
nivel
de
predicMbilidad
de
Java
EE
con
Java
de
Mempo
real
+
Requisitos
y
niveles
+
Arquitectura
+
Evidencia
empírica
CEDI-‐13
16
17. Trabajo
futuro
• Alinear
este
trabajo
con
Java
EE
8
– Cuando
este
salga
(2014??)
• Completar
los
niveles
con
nuevas
estrategias
tomadas
del
estado
del
arte
– Coste
de
la
seguridad
(JAAS)
– Algoritmos
de
planificación
elásMcos
CEDI-‐13
17