Intro
Siguiendo en la linea de la introspección, hoy vamos a ver una simple reflexión que nos va a permitir invocar sobre una instancia de una clase a métodos por su nombre.
Intro
Siguiendo en la linea de la introspección, hoy vamos a ver una simple reflexión que nos va a permitir invocar sobre una instancia de una clase a métodos por su nombre.
Este es el último artículo de esta serie. En este voy a presentar como se configura el servidor y además voy a subir el código fuente.
Siguiendo la exploración de los principales componentes de servidor, en este artículo vamos a ver el el componente de conexiones a la base de datos y el de mensajería. Los dos componentes se diseñaron e implementaron separadamente del servidor de aplicaciones, por lo que no están acoplados de ninguna forma. Para “agregarlos” al servidor, se implementaron módulos del servidor que los adaptan. » Read more: Java AppServer-02: DBPool + Messaging
Ahora que tenemos un servicio RPC podemos usarlo como base para implementar un servidor de aplicaciones, pero solamente un servicio RPC no alcanza. Por esto, vamos a implementar estos módulos/servicios:
Seguridad: autorización, autenticación y auditoria
Pool de conexiones a la base de datos
Servicio de mensajería asíncrona
En este es último artículo de la serie RPC voy explorar algunas extras que tiene el servidor que nos van a servir para implementar un servidor de aplicaciones, pero sin perder generalidad. También vamos ha realizar un test de rendimiento, viendo el througput (pedidos por segundo) que tiene el servidor.
Intro
Una de las características que más se extrañan a la hora de utilizar GWT es la capacidad de Java de realizar introspección sobre beans. La causa de esta limitación es que GWT no tiene emulación la API reflexión (java.lang.reflect). En este artículo vamos a ver como podemos implementar una suerte de introspección en GWT. También vamos a explorar algunas aplicaciones de introspección, ya que en principio no es trivial su utilidad.
En el artículo anterior vimos como estaba estructurada la capa Servicio y cuales eran las ideas principales. Pero para que sea realmente útil, nos quedaba responder las siguientes dos preguntas:
¿Cómo vamos a hacer para crear una instancia que sea un proxy de la clase MathServiceImpl, que implemente la interfaz MathService en forma automática y en tiempo de ejecución?
¿Cómo vamos a hacer un RequestListener genérico que “decodifique” el RequestPacket e invoque al método correcto de MathServiceImpl?
Ahora si, la capa final. Lo que tiene que hacer esta capa es dar una interfaz amigable con el desarrollador para agregar y consumir servicios. Vimos que la API que daba la capa Pedido no era mala, pero se puede mejorar; tanto que podemos hacer que se parezca mucho a una invocación local. Idealmente queremos que tenga la misma sintaxis y semántica que en una llamada local.
Hoy examinaremos una de las capas más complejas del sistema, la capa Request. Comparando esta capa con las anteriores (Conexión y Sesión) que son básicamente pasa-mano, esta capa agrega buena parte de la complejidad del sistema. ¿Por qué? Porque es la encargada del manejo de pedidos y respuestas concurrentes entre los clientes y el servidor.
Hoy veremos la capa Sesión. Como el nombre lo indica, la idea de esta capa es la de representar la sesión, tanto para el cliente como para el servidor. En el cliente va a haber una única sesión, mientras en el servidor van a existir una por cada cliente conectado. La principal responsabilidad de esta capa es mantener el estado del cliente del lado del servidor.