NullBrainException, Java en Español

Java Virtual Machine

Una máquina virtual Java (en inglés Java Virtual Machine, JVM) es una máquina virtual de proceso nativo, es decir, ejecutable en una plataforma específica, capaz de interpretar y ejecutar instrucciones expresadas en un código binario especial (el bytecode Java), el cual es generado por el compilador del lenguaje Java.

Java Web Development

Como instalar Eclipse y Tomcat para desarrollo con Java?

Ahora vamos a ver cómo comenzar a crear proyectos web en Java, mediante las herramientas Eclipse y Tomcat.

Aplicaciones Web Escalables: eBay

Hay pocas aplicaciones web como eBay que ejemplifiquen tan bien las necesidades de una empresa para escalar y satisfacer la demanda. eBay tiene 88.3 millones de usuarios activos en todo el mundo, más de 2 mil millones de páginas mostradas por día, y 48 mil millones de ejecuciones SQL por día. Randy Shoup, arquitecto de la web de eBay y el arquitecto principal de la infraestructura de búsqueda del sitio, nos cuenta cómo hacen para satisfacer esta demanda.

Apache Commons Lang

Hay varias porciones de código y tareas que debemos repetir en varios programas Java, sin importar de qué se traten funcionalmente. Muchas veces el JDK nos es de ayuda, pero otras tantas veces necesitamos métodos "utilitarios" que no están por ningún lado en el JDK... y en consecuencia terminamos programando estas funciones "a mano" para cada proyecto.

Java Web Portals

Los Portales Web son sitios que actúan como un punto único de acceso para una gran cantidad de información. En Java es posible crear componentes para extender la funcionalidad de estos portales. De esto se ocupa el API de Portlets.

En este artículo veremos una introducción a los Portales Web, un Portlet 2.0 de ejemplo y la anatomía general de un Portlet.

Dozer

Dozer es una librería Java para mapear Java Beans que copia de manera recursiva los datos, de un objeto a otro. Usualmente, estos Java Beans van a contener distintos tipos complejos.

Acoplamiento y Cohesión

El acoplamiento y la cohesión juegan un rol central en el diseño de software. Yourdon y Constantine, en su obra clásica Diseño Estructurado, identifican que el objetivo del diseño es minimizar los costos. El costo del software está determinado por el costo de mantenimiento, y el costo del mantenimiento está determinado por el costo de los cambios que surgen en el sistema. Un diseño de software efectivo minimiza la probabilidad de que se propaguen los cambios. Los cambios que involucran a un único elemento son menos costosos y más predecibles que los cambios a un elemento que requieren cambiar dos más, y luego tres...

El costo esperado del cambio se puede reducir prestando especial atención a dos factores: el acoplamiento entre los elementos y lacohesión dentro de los elementos.

(El diseño de software también es importante para incrementar o acelerar las ganancias, pero las ganancias no están directamente conectadas al acoplamiento y la cohesión)

Acoplamiento

Dos elementos están acoplados en la medida en el que los cambios en uno tienden a necesitar cambios en el otro. Por ejemplo, la comunicación por red entre dos sistemas está acoplada respecto a cambios en el protocolo - si un sistema necesita ambiar el protocolo, el otro va a necesitar cambiar también. El acoplamiento entre los elementos es un conductor de cambios.

El acoplamiento propaga los cambios

Hablamos de acoplamiento (y cohesión) en términos de cambios particulares. Esta no es la definición estándar. El acoplamiento suele definirse como una propiedad estática: dos elementos están temporalmente acoplados si, por ejemplo, la secuencia invocante entre ellos está restringida. Estas propiedades estáticas son sólo costo potencial: si no ocurre ningún evento que dispare el acoplamiento, el costo nunca ocurre.

Un sistema podría estar acoplado a un proveedor de bases de datos específico, al utilizar características propias de ese proveedor (por ejemplo, de Oracle). Un cambio en la base de datos va a provocar cambios al sistema. Sin embargo, si la base de datos nunca cambia, entonces el acoplamiento es sólo potencial. Evaluar el costo del acoplamiento con precisión requiere de la evaluación del grupo de cambios que son realmente requeridos en el sistema. Y esto sólo puede hacerse a posteriori. Evaluar los costos en retrospectiva requiere estimar la probabilidad de los tipos de cambios que se propagarían a través de relaciones.

La relación entre el acoplamiento y el costo del cambio funciona en ambos sentidos. Los cambios que parecen ser más costosos van a ser menos probables que se elijan para hacer. Al romper el acomplamiento se crean oportunidades para nuevos tipos de cambios, antes imposibles de pensar.

Hay mucho más para decir sobre los distintos tipos de acomplamiento, y los tipos de cambios que se propagan. El concepto fundamental es que los elementos en un diseño no deben estar acoplados con respecto a los cambios que realmente van a ocurrir. Esto mantiene contenido al costo de los cambios.

Cohesión

El acoplamiento mide la dispersión del cambio a través de los elementos. La cohesión mide el costo del cambio dentro de un elemento. Un elemento es cohesivo a medida que cambia el elemento entero cuando el sistema necesita cambiar.

Un elemento puede tener poca cohesión tanto por ser muy grande o muy pequeño. Un elemento muy pequeño, que resuelve sólo una parte del problema, va a necesitar estar acoplado a otros elementos para resolver las otras partes del problema. Si cambia la solución se va a necesitar cambiar todos los elementos. Un elemento que resuelve muchos problemas sólo va a necesitar cambiarse en parte. Esto es más riesgoso y más costoso que cambiar un elemento completo, porque primero se necesita averiguar qué parte del elemento debe cambiarse, y luego probar que las partes sin cambios del elemento realmente sigan sin cambios. Los elementos cohesivos, que se reemplazan en su totalidad, no tienen estos costos.

La estrategia de aislar los cambios es una forma de inducir la cohesión antes de hacer un cambio; por ejemplo, extraer la parte de un método que necesita cambiarse dentro de un método propio antes de hacer el cambio.

Balance

Una de las cosas que hace divertido al diseño es que necesita ser balanceado. Si los elementos son muy grandes, cada cambio va a ser más costoso de lo que necesita ser. Si los elementos son muy chicos, los cambios van a esparcirse por todo el sistema. Y la optimización del diseño ocurre sobre un flujo impredecible de cambios.

Drools

Drools es un motor de reglas Java que se encarga de aplicar reglas de negocio dentro de nuestras aplicaciones. De esta manera aparece el concepto de Sistema de Administración de Reglas de Negocio (BRMS - Business Rules Management System), el cual nos permite parametrizar las reglas del negocio de forma externa a la aplicación que las utiliza.