Mejoras a la predictibilidad de la tecnología Java EE

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

Í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

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

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

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

Requisitos

(2/2)

•  [Req4]
Dar
cabida
a
elementos
especíﬁcos

de
Java
EE

•  [Dis.R4]
Hay
que
ver
cada
servicio
uno
a
uno
para
poder

decidir
sobre
su
relación
beneﬁcio
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

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

–  Suﬁciente
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
beneﬁcio
tecnológico

CEDI-‐13
7

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

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
deﬁnir
caracterísMcas
no

funcionales

– 
ﬁcheros
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

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

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)

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: }

Resultados
empíricos

•  ObjeMvo:
Comprobar
las

relaciones
de
coste/beneﬁcio
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)

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

Relaciones
coste/beneﬁcio

•  Coste
máximo
de
Java
de
Mempo

real

–  (24%)

•  Beneﬁcio
máximo
de
Java
de

Mempo
real

–  (58%)

CEDI-‐13
15

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

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
planiﬁcación
elásMcos

CEDI-‐13
17

Mejoras a la predictibilidad de la tecnología Java EE

Más contenido relacionado

Similar a Mejoras a la predictibilidad de la tecnología Java EE (20)

Más de Universidad Carlos III de Madrid (12)

Mejoras a la predictibilidad de la tecnología Java EE