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.
Como la velocidad de la luz es mayor que la del sonido, ciertas personas parecen brillantes antes de que escuchemos las pelotudeces que dicen.
Mostrando entradas con la etiqueta Java. Mostrar todas las entradas
Mostrando entradas con la etiqueta Java. Mostrar todas las entradas
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.
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.
Spring Anottation Controller
Spring Framework nos permiten la creación de Controllers mediante anotaciones. Mostraremos un sencillo ejemplo utilizando Spring Framework 3.0
Spring REST
Spring Framework 3.x trae la posibilidad de crear servicios web REST de manera muy simple.
Spring Web Service
Spring Framework tiene un soporte para poder invocar web services de forma muy simple.
A continuación vamos a ver un ejemplo concreto invocando a un Web Service de prueba.
Message Driven Bean
Message Driven Beans (o MDB) son un tipo de EJB para integración con mensajería JMS (Java Message Service).
Los MDB son objetos distribuidos que se crean para manipular asincrónicamente los mensajes JMS. Es decir, realizan las operaciones que no requieren una respuesta inmediata.
Test Driven Development
Desarrollo guiado por pruebas, o Test Driven Development (TDD) es una práctica de programación que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización (Refactoring). Para escribir las pruebas generalmente se utiliza la Prueba Unitaria (unit test en inglés).
JUnit
JUnit es un framework de código abierto desarrollado especialmente para crear, ejecutar y hacer reportes de estado de conjuntos de Prueba Unitaria automatizadas hechos en lenguaje Java.
JUnit es uno de los frameworks más populares en Java para realizar pruebas unitarias y llevar un desarrollo utilizando la práctica deTest Driven Development.
Ejemplo De JMS
Haciendo tostadas
Vamos entonces a hacer que nuestras aplicaciones Dib y Gaz se comuniquen con una cola de mensajes. Lo que haremos a continuación será:
- Crear una cola en WebLogic (la heladera para pegar los mensajes)
- Crear una aplicación que publique mensajes en la cola (Dib)
- Crear un EJB que consuma los mensajes de la cola (Gaz)
Log4J
Log4J es una librería para resolver el log de aplicaciones Java.
Los Appender
Log4J utiliza "appenders" para guardar el log generado por las aplicaciones. Un appender es el encargado de procesar un mensaje de log enviado por la aplicación. Usualmente se encarga de almacenarlo en algún medio persistente, como ser un archivo.
EhCache
EhCache es uno de los frameworks más utilizados para el Cache De Objetos Java.
En general, EhCache consta de "regiones de cache" en donde se ubican objetos. Estas regiones se configuran en un archivo XML para determinar el tiempo de expiración, cantidad máxima de elementos, etc.
Ejemplo
Crearemos una región de cache llamada "dosIdeas". Luego, veremos cómo subir un objeto a dicha región, y cómo recuperarlo.
Archivo de configuración ehcache.xml
El archivo ehcache.xml tiene que residir en la raiz del classpath. En la raiz del jar de ehcache hay un archivo de configuración de ejemplo (ehcache-failsafe.xml), que tiene configurada una región predeterminada. Podemos copiar este archivo a nuestro proyecto y renombrarlo como ehcache.xml. A dicho archivo el agregaremos un región llamada "dosIdeas". Esta región mantendrá los elementos durante 1 segundo, y luego serán borrados de la región (atributo timeToLiveSeconds).
name="dosIdeas"
maxElementsInMemory="10000"
maxElementsOnDisk="1000"
eternal="false"
overflowToDisk="true"
timeToIdleSeconds="300"
timeToLiveSeconds="1"
memoryStoreEvictionPolicy="LFU"
/>Accediendo al caché
Subiremos un elemento al cache, y luego lo recuperaremos. Por último, esperaremos unos segundos y veremos cómo al volver a recuperar el objeto, el mismo no está más. Este método se ejecuta dentro de un test de JUnit
@Test
public void testCache() throws InterruptedException {
Persona persona = new Persona();
persona.setId("1");
persona.setNombre("Zim");
CacheManager manager = new CacheManager();
Cache cache = manager.getCache("dosIdeas");
//al cache se suben objetos Element. Un element consta de una clave y un valor.
//La clave sera el medio para recuperar el objeto mas tarde. En el ejemplo, el "id" de la Persona.
Element element = new Element(persona.getId(), persona);
cache.put(element);
Persona personaCache = (Persona) cache.get(persona.getId()).getObjectValue();
assertEquals(persona, personaCache);
//esperamos unos instantes para que expire el cache...
Thread.sleep(1500);
assertNull(cache.get(persona.getId()));
}
Ver también
EhCache Spring
Spring Framework se integra perfectamente con EhCache, tanto sea a través de clases utilitarias "oficiales" como usando librerías adicionales que brindan una mejor integración.
Java equal() y hashcode()
Todos los objetos en Java tiene dos métodos muy importantes: el método hashCode() y el método equals(). Estos métodos están diseñados para ser sobreescritos de acuerdo a su contrato general.
En este artículo veremos porqué y cómo sobreescribir el método hashCode() que cumpla con el contrato para los HashCode.
Ejecutar Quartz jobs a pedido
Cuando desarrollamos aplicación con spring, quartz y la configuración de los jobs queda empaquetada en la aplicación, resulta bastante molesto tener que cambiar la configuración, recompilar y desplegar nuevamente la aplicación, en algunos casos hasta se tiene que volver a la configuración inicial luego de una sola ejecución.
Spring Framework 3.0
Después de varios meses de trabajo ya está disponible Spring Framework 3.0 GA, la nueva versión del popular framework de aplicaciones para Java. Esta nueva versión aprovecha características de Java EE 6 (por ejemplo, usando GlassFish v3) y soporta JPA 2.0 (por ejemplo, usando EclipseLink 2.0). También se incluye soporte para la nueva anotación @ManagedBean (JSR-250) para escanear componentes, que complementa el soporte para la anotacion @Inject (JSR-330) para inyección de dependencias a través de anotaciones.
Hibernate: Métodos get() y load()
Hibernate, al igual que la vida, está lleno de sopresas. Hoy vamos a compartir una de estas sorpresas: ¿se dieron cuenta que Hibernate tiene dos métodos para cargar una entidad persistente de la base de datos? Estos dos métodos son get(Class, Serializable) y load(Class, Serializable), pertenecientes a la clase Session y sus variantes.
Apache Solr
Apache Solr es una plataforma de búsquedas basada en Apache Lucene, que funciona como un "servidor de búsquedas". Sus principales características incluyen búsquedas de texto completo, resaltado de resultados, clustering dinámico, y manejo de documentos ricos (como Word y PDF). Solr es escalable, permitiendo realizar búsquedas distribuidas y replicación de índices, y actualmente se está usando en muchos de los sitios más grandes de Internet.
Suscribirse a:
Entradas (Atom)