Java RPC-06: Capa Servicio

Septiembre 2nd, 2009 por Enrique 2 comments »

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?

» Read more: Java RPC-06: Capa Servicio

  • Blogger Post
  • Digg
  • Reddit
  • Google Reader
  • Share/Bookmark

Java RPC-05: Capa Servicio

Agosto 30th, 2009 por Enrique No comments »

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.

» Read more: Java RPC-05: Capa Servicio

  • Blogger Post
  • Digg
  • Reddit
  • Google Reader
  • Share/Bookmark

Java RPC-04: Capa Pedido

Agosto 27th, 2009 por Enrique No comments »

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.

» Read more: Java RPC-04: Capa Pedido

  • Blogger Post
  • Digg
  • Reddit
  • Google Reader
  • Share/Bookmark

Java RPC-03: Capa Sesión

Agosto 24th, 2009 por Enrique No comments »

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.

» Read more: Java RPC-03: Capa Sesión

  • Blogger Post
  • Digg
  • Reddit
  • Google Reader
  • Share/Bookmark

Java RPC-02: Capa Conexión

Agosto 21st, 2009 por Enrique No comments »

En el artículo anterior, vimos la arquitectura del sistema; en este vamos a explorar la capa Conexión.

Para comenzar, recordemos que la responsabilidad de esta capa es comunicar al cliente y al servidor mediante la red. La capa conexión que se va a implementar va a ser sobre TCP/IP, pero el diseño permite que se pueda implementar sobre otros protocolos.

» Read more: Java RPC-02: Capa Conexión

  • Blogger Post
  • Digg
  • Reddit
  • Google Reader
  • Share/Bookmark

Java RPC-01: Arquitectura

Agosto 18th, 2009 por Enrique No comments »

Este es el primero de una serie de artículos en los cuales presentaré el diseño y desarrollo de un mecanismo RPC en Java. Este RPC va a ser multi-hilo del lado del servidor para que pueda atender varios pedidos a la vez; y también va a ser multi-hilo del lado del cliente para que pueda realizar varios pedidos a la vez al servidor.

» Read more: Java RPC-01: Arquitectura

  • Blogger Post
  • Digg
  • Reddit
  • Google Reader
  • Share/Bookmark

Lanzamiento de Labs

Agosto 17th, 2009 por Enrique No comments »

Con este post, damos por inaugurada la sección Labs del blog.

En esta sección se tratará todo lo concerniente a la experimentación con distintos lenguajes de programación.

En el primer artículo (en el cual estoy trabajando) implementaremos RPC en Java. Para que sea “divertido”, este RPC va a ser multi-hilo del lado del servidor (capacidad de atender muchos pedidos a la vez) y también multi-hilo del lado del cliente (capacidad hacer múltiples invocaciones a la vez)

Hasta pronto!

  • Blogger Post
  • Digg
  • Reddit
  • Google Reader
  • Share/Bookmark

SCRUM Overview

Agosto 16th, 2009 por Gabriel No comments »

INTRODUCCIÓN

SCRUM es una metodología ágil que surge como una alternativa a las tradicionales. Las metodologías ágiles proponen un marco de gestión de proyectos más pragmático y menos burocrático. Surgieron a mitad de los años 80 en Japón, partiendo de la premisa que el valor agregado está en la gente y especialmente en la capacidad de auto-organización de las personas.

A continuación se citan las premisas en las cuales está basado SCRUM, llamado “Manifiesto Ágil”:

  • Valorar mas a los individuos y su interacción que a los procesos y las herramientas.

  • Valorar mas el producto que funciona que la documentación exhaustiva.

  • Valorar mas la colaboración con el cliente que la negociación contractual.

  • Valorar mas la respuesta al cambio que el seguimiento de un plan.

La palabra SCRUM significa lo mismo que en el Rugby, es decir, en este deporte se adopta una figura de juego en la cual un equipo tiene que actuar muy coordinado y con fuerza constante para lograr el balón. En la medida que se aprende y practica esta metodología esta palabra va tomando significado.

En resumen lo que propone SCRUM es un marco de trabajo, un camino simple y claro con una serie de artefactos, roles y rituales que permiten transitarlo en base a iteraciones basadas en inspeccionar y adaptar en donde cada vez que una culmina se debe haber alcanzado un producto que en sí mismo tenga retorno de inversión para el cliente.


ROLES

Scrum Master: Es ejecutado por un individuo, éste se encarga de facilitar absolutamente todo lo que se necesita para cumplir con las metas del proyecto. Su rol fundamental será hacer cumplir la metodología.

Product Owner: También es ejecutado por una sola persona, en general es alguién que conoce perfectamente cúal es el retorno de inversión de cada uno de los requerimientos que tiene el proyecto. Es decir, debe conocer muy bien el producto que se desea obtener.

Team: Es el equipo de trabajo, lo integran quienes vayan a implementar el proyecto. Se recomienda que no haya menos de 5 integrantes ni más de 9.


CICLO DE VIDA DEL PROYECTO

El ciclo de vida de un proyecto Scrum se basa en unidades iterativas que deben tener un tiempo fijo en las cuales se planifica, desarrolla y aprueba el resultado de esa iteración. Estas unidades iterativas se llaman SPRINTS. Se sugiere que un Sprint tenga una duración mínima de una semana y una máxima de cuatro.


RITUALES

Se les llama rituales a las reuniones que establece SCRUM que deben ser cumplidas en esta metodología.

Sprint Planning: Al comenzar un nuevo Sprint se debe tomar la lista de requerimientos (Product Backlog) y a partir de la prioridad de cada uno se debe seleccionar un conjunto de estos requerimientos los cuales serán ejecutados por el Team. Este subconjunto de requerimientos deben generar valor de retorno de inversión al cliente y debe ser un producto potencialmente entregable. En esta reunión participan el SM, PO y el Team. El tiempo de duración máxima son 2 horas.

Sprint Daily Meeting: Diariamente el Team debe realizar una reunión en donde cada integrante tiene 2 minutos para responder a las siguientes preguntas:

  1. ¿Qué tareas comprometidas realizó?

  2. ¿Qué impedimientos detectó al realizar estas tareas?

  3. ¿Qué tareas se compromete a realizar mañana?

En esta reunión debe participar el Team y el SM. Se puede realizar en cualquier momento del día, eso lo define el Team, una vez definido no debería ser modificado.

Sprint Review: Al finalizar un Sprint se debe realizar una revisión del producto concebido en ese Sprint. Para ello deberán reunirse el Team, el PO y el SM. Esta reunión deberá tener como resultado una aprobación o reprobación del producto por parte del cliente. Se recomienda una duración máxima de 2 horas.

Sprint Retrospective: Luego de realizar el Sprint Review se deberá realizar otra reunión entre el SM y el Team. El propósito de esta es realizar un análisis para ver cómo se aplicó la metodología y realizar una evaluación del resultado en donde se deberán tener en cuenta las correcciones que se deben aplicar para la siguiente iteración.


ARTEFACTOS

Product Backlog: Es una lista de requerimientos que definen el producto que el cliente necesita. Cada requerimiento se llama Item Product Backlog.

Product Backlog Comprometido: Es un subconjunto de los ItemProductBacklog que están comprometidos para un Sprint determinado.

Charts: Scrum propone una serie de reportes o gráficas que permiten tomar indicadores del proyecto, alguno de ellos son:

  • Burndown Chart: Permite ver cuanto falta para finalizar el proyecto.

  • Velocity: Permite obtener una cuantificación de la velocidad de desempeño del Team.

REFERENCIAS

  • Blogger Post
  • Digg
  • Reddit
  • Google Reader
  • Share/Bookmark

Blog de AQuA.it

Agosto 6th, 2009 por Enrique 1 comment »

En este blog los integrantes de AQuA.it comenzarán a escribir sobre su experiencia profesional.

Esperamos en breve estar en contacto.

Gracias

  • Blogger Post
  • Digg
  • Reddit
  • Google Reader
  • Share/Bookmark