Mejoras a la predictibilidad de la tecnología Java EE
-
Upload
universidad-carlos-iii-de-madrid -
Category
Documents
-
view
186 -
download
3
Transcript of 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:[email protected]
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.bil idad 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í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
• [Req6 ] 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 – 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
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 SCJJava de
tiempo real
Java EE de tiempo real
Aplicacionesempresarialesde 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_Params{ 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
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 EEDe tiempo real
Servo ServoBean
Internet
AccessServ
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: @EJB03: 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 EEDe tiempo real
Servo ServoBean
Internet
AccessServ
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 EEDe tiempo real
Servo ServoBean
Internet
AccessServ
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/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)
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/beneficio
• Coste máximo de Java de Mempo real – (24%)
• Beneficio 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 planificación elásMcos
CEDI-‐13 17
18