viernes, diciembre 10, 2010

Sistemas de Información Ejecutiva (EIS)

Un Sistema de Información para Ejecutivos o Sistema de Información Ejecutiva es una herramienta software, basada en un DSS, que provee a los gerentes de un acceso sencillo a información interna y externa de su compañía, y que es relevante para sus factores clave de éxito.

La finalidad principal es que el ejecutivo tenga a su disposición un panorama completo del estado de los indicadores de negocio que le afectan al instante, manteniendo también la posibilidad de analizar con detalle aquellos que no estén cumpliendo con las expectativas establecidas, para determinar el plan de acción más adecuado.

De forma más pragmática, se puede definir un EIS como una aplicación informática que muestra informes y listados (query & reporting) de las diferentes áreas de negocio, de forma consolidada, para facilitar la monitorización de la empresa o de una unidad de la misma.

El EIS se caracteriza por ofrecer al ejecutivo un acceso rápido y efectivo a la información compartida, utilizando interfaces gráficas visuales e intutivas. Suele incluir alertas e informes basados en excepción, así como históricos y análisis de tendencias. También es frecuente que permita la domiciliación por correo de los informes más relevantes.

A través de esta solución se puede contar con un resumen del comportamiento de una organización o área específica, y poder compararla a través del tiempo. Es posible, además, ajustar la visión de la información a la teoría de Balanced Scorecard o Cuadro de Mando Integral impulsada por Norton y Kaplan, o bien a cualquier modelo estratégico de indicadores que maneje la compañía.

Si no está familiarizado con el concepto de Sistema de Información Ejecutiva, puede resultarle útil, además, examinar las siguientes definiciones:

Cuadro de Mando Integral

Sistemas de Soporte a la Decisión (DSS)

Datamining

Datamart

Datawarehouse

martes, diciembre 07, 2010

Tomcat y configuraciones

Tomado de: Tomcat

Contendores del tomcat

2 Noviembre 2009

Context Container
El Context element representa una aplicación web, que se ejecuta en un host virtual. Cada aplicacion se basa en un archivo de aplicación (WAR), o un directorio que contiene los elementos descomprimidos.
Catalina decide que plicación que procesa una petición HTTP basándose en la URI comparandola con la ruta del contexto. Una vez que se seleciona el contexto, éste decidira el servlet para procesar la petición de acuerdo con los mapeos de los servlets definidos en el descriptor de la aplicación web (web.xml) que se encuentra en /WEB-INF/web.xml.
Se pueden definir tantos contextos como se quiera, teninedo en cuenta que cada contexto tiene que tener una ruta única, además, debe de existir un contexto con una ruta con una ruta cuya longitud sea cero. Este contexto es el contexto por defecto para los hosts virtuales y se usa para procesar todas las peticiones que no coinciden con ningún contexto.
A partir del Tomcat 5, no se recomienda poner elementos directamente en el server.xml. Esto es porque no es posible modificar la configuración del contexto en el fichero server.xml y recargar dicha configuración sin reiniciar el Tomcat.
Los contextos se pueden definir explicitamente en:
$CATALINA_HOME/conf/context.xml: La información del contexto se cargaran por todas las aplicaciones.
$CATALINA_HOME/conf/[enginename]/[hostname]/context.xml : La información del contexto se cargara por todas las aplicaciones en ese host virtual.
Engine Container
El Engine representa todo el proceso de peticiones asociados a un servicio del catalina en particular, recibe y procesa todas las peticiones de uno o más conectores devolciendo el response completo al conector para que se la devuelva al cliente.
Tiene que existir un engine dentro de un sericio, seguido de todos los conectores asociados al servicio.
Host Container
El elemento host representa un host virtual, que representa una asociación al dominio (por ejemplo “www.google.com”) con el servidor Catalina sobre el que se ejecuta. Para que funcione correctamente se tiene que registrar la DNS.
Para poder asociar mas de un dominio a un host se tiene que usan los alias. Se pueden asociar mas de un host a un Engine. Dentro del host se puede anidar los contextos de las aplicaciones web asociados al host virtual. Al menos uno de tiene que ser el defaultHost del Engine.

Escrito en Servidores de aplicaciones | Etiquetado containers, contendores, Tomcat | Deja un Comentario »

Válvulas de Tomcat

2 Noviembre 2009

¿Qué es una válvula del tomcat?
Las válvulas del tomcat son una técnología introducida a partir de Tomcat 4 que permite asociar una instacia de una clase Java al un contenedor Catalina.
Esta configuración permite que la clase asociada actue como un pre-procesador de las peticiones. Estas clases se llaman válvulas, y deben implementar la intefaz org.apache.catalina.Valve interface o extender la clase org.apache.catalina.valves.ValveBase. Las válvulas son propias de Tomcat y no pueden ser usadas en otros contenedores de servlet. Las válvulas disponibles son:
- Access Log
- Remote Address Filter
- Remote Host Filter
- Request Dumper
- Single Sign On
- Form Authenticator
Access Log Valve
La primera válvula por defecto del tomcat es Access Log Valve, que está implementada por la clase org.apache.catalina.valves.AccessLogValve. Crea ficheros de log para rastrear el acceso a la información de los clientes.
Alguna de la infomación que rastrea son clicks, actividad de la sesión del usuario, información de la autenticación del usuario entre otras. Esta válvula se puede asociar a un engine, host o context container del Tomcat.
Ejemplo de uso :

`1`	`<Valve` `className="org.apache.catalina.valves.AccessLogValve"` `directory="logs"` `prefix="localhost_access_log."` `suffix=".txt"` `pattern="common"/>`

Este código indica que los logs se guardaran en el directorio /logs, con el prefijo “localhost_access_log.”, y con el sufijo “.txt”.
Remote Address Filter
El Remote Address filter lo implementa la clase org.apache.catalina.valves.RemoteAddrValve, permite comparar direcciones IP de los clientes que realizan la petición con una o varias expresiones regulares para prohibir o permitir el acceso. Esta válvula se puede asociar al Engine, Host, o Context container.
Ejemplo de uso:

`1`	`<Valve` `className="org.apache.catalina.valves.RemoteAddrValve"` `deny="127.*"/>`

Esta sentencia prohibe el acceso a todos los clientes cuya IP empiecen por 127.
Remote Host Filter
El Remote Host filter está implementado por org.apache.catalina.valves.RemoteHostValve es muy parecido al RemoteAddrValve, con la diferencia que te permite comparar al nombre del host en vez de la IP. Se puede asociar al Engine, Host, o Context container.
Ejemplo de uso:

`1`	`<Valve` `className="org.apache.catalina.valves.RemoteHostValve"` `deny="virtuas*"/>`

Con esta sentencia prohibimos el acceso a todos los host con que incluyan en su nombre virtuas.
Request Dumper Valve
ElRequest Dumper valve lo implenta la clase org.apache.catalina.valves.RequestDumperValve es una herramienta de depuración que escribe en el log el detalle de cada petición realizada. Se puede asociar al Engine, Host, o Context container.
Ejemplo de uso:

`1`	`<Valve` `className="org.apache.catalina.valves.RequestDumperValve"/>`

Si accedemos a cualquier aplicación en localhost:8080 y accedemos al log, veremos unas cuantas entradas realizadas por el RequestDumperValve.
Single Sing On
Esta válvula se utiliza cuando queremos que los usuarios puedan identificarse en cualquier aplicacion en nuestro virtual host, y que su identidad sea reconocida por cualquier aplicación que esté en ese host.
Ejemplo de uso:

`1`	`<Valve` `className="org.apache.catalina.authenticator.SingleSignOn"` `/>`

Form Authenticator Valve
Se añade automáticamente al Context cuando este se configura para usar autenticación mediante FORM.

Escrito en Servidores de aplicaciones, Uncategorized | Etiquetado Tomcat, valve | Deja un Comentario »

Control de accesos por IP a Tomcat

9 Octubre 2009

Hace poco tuve que capar el acceso a una aplicación por IP, barajamos varias opciones y al final el personal de sistemas tomó una decisión. De todas formas me pareció muy interesante usar las valve o válvulas de Tomcat para hacerlo. Nunca lo había hecho, ni sabía que se podía hacer con el propio Tomcat, siempre había pensado en firewalls o apache, o cualquier otra cosa. La verdad es que nunca tuve que ver como se hacía hasta ahora.
Para hacerlo hay que hacer lo siguiente:
En el fichero server.xml, dentro del Host localhost, ponemos lo siguiente:

`1`	`<Valve` `lassName="org.apache.catalina.valves.RemoteAddrValve"` `deny="192.164.1.*">`

En este caso prohibimos el acceso a todas las direcciones IP que concuerden con 192.164.1.*, se pueden poner más si separamos las IPs con “,”. También se puede definir el parámetro “allow” que se usa de la misma forma, en este caso todas las IPs que no concuerden con nuestra expresión, no podrán tener acceso.

Escrito en Servidores de aplicaciones | Etiquetado acceso, control, ip, Tomcat | Deja un Comentario »

Vulnerabilidades en Tomcat

9 Octubre 2009

Se han encontrado varios dos fallos de seguridad en las siguientes versiones de tomcat:
Tomcat 4.1.0 al 4.1.37
Tomcat 5.5.0 al 5.5.26
Tomcat 6.0.0 al 6.0.16
Estas vulnerabilidades son:
1)En el RequestDispatcher la ruta de destino se normalizó antes de que la cadena de consulta se ha retirado. Por lo tanto si se pone un parámetro malicioso en la consulta se puede conseguir acceder a información restringida o información que se encuentre en el WEB-IND
Ejemplo:
Una página que tenga:

<%

pageContext.forward("/page2.jsp?somepar=someval&par="+request.getParamet

er("blah"));

%>

El hacker puede usar:

http://host/page.jsp?blah=/../WEB-INF/web.xml

2) HttpServletResponse.sendError () no es sólo aparece en la página de error, también se utiliza en el HTTP response. Esto puede incluir caracteres que son ilegales en las cabeceras HTTP. Con un esto se puede conseguir un ataque XSS, al inyectar contenido arbitrario en la respuesta HTTP.
Por ejemplo:
<%@page contentType=”text/html”%>

<%

final String CRLF = "\u010D\u010A";

final String payload = CRLF + CRLF + "<script

type='text/javascript'>document.write('Hi, there!')</script><div style='display:none'>";

final String message = "Authorization is required to access " + payload;

response.sendError(403, message);

%>

Escrito en Servidores de aplicaciones | Etiquetado Tomcat, vulnerabilidad | Deja un Comentario »

Comunicación entre contextos

9 Octubre 2009

En uno de los proyectos en los que trabajo, tengo la necesidad de compartir variables entre dos contextos que se encuentran en el mismo Tomcat y descubrí el CrossContext que es un atributo de configuración de tomcat que sirve para que las diferentes aplicaciones en el servidor compartan el contexto.

Se tiene que modificar el fichero conf/server.xml del tomcat añadiendo las siguientes líneas dentro del tag <host>:

Con el “crossContext = true” indicamos a los dos proyectos que van a compartir información.

Se tiene que modificar el fichero conf/server.xml del tomcat añadiendo las siguientes líneas dentro del tag <host>:

Con el “crossContext = true” indicamos a los dos proyectos que van a compartir información.

Ahora en una de las aplicaciones podemos poner algo así:

application.setAttribute(”variable”,”hola”);

En la otra ponemos

ServletContext sc = pageContext.getServletContext().getContext(”/miaplicacion2″); //inicializa el servlerContext con el nombre de la aplicación de la que queremos //obtener el contexto

out.println(sc.getAttribute(”variable”));

Escrito en Servidores de aplicaciones | Etiquetado contextos, Tomcat | Deja un Comentario »

El log de Tomcat

22 Enero 2009

Hoy he tenido un problema, me he dado cuenta de que mi log del tomcat era demasiado grande, 6 Gb; Lo cual me llamo la atención, ya que sabía, que por defecto el log de tomcat se define como “rotable” es decir, que se rotan los logs una vez al día. Miré si era problema de premisos y no, era problema de configuración. Así que desempolve mi libro de tomcat y lo configuré bien. De ahí, que hoy haya decidido explicar un poco este tema.

Desde el Tomcat 4, existe un concepto que se conoce como “valve” que permite asociar una instancia de una clase java a un contenedor Catalina. De esta forma, asociando el nombre de la clase, podemos hacer que esta actue como un preprocesador de cada solicitud. Estas clases deben implementar la clase org.apache.catalina.Valve o extender la org.apache.catalina.valves.ValveBase clase. Tomcat viene configurado con cuatro válvulas:

- Access Log

- Remote Address Filter

- Remote Host Filter

- Request Dumper

Me voy a centrar en la primera, la válvula del log o LogAccessValve, la clase es org.apache.catalina.valves.AccessLogValve. Cuya misión es crear archivos de log para seguir el seguimiento de la aplicación del servidor de aplicaciones o de la aplicación si deseamos usar este log y no uno propio para ello. Algunos de las seguimientos que hace esta válvula es hit counts, actividad de la sesión del usuario, la autenticación de los usuarios, entre otros.
El siguiente fragmento de código es un ejemplo usando la entrada org.apache.catalina.valves.AccessLogValve:

Este fragmento de código establece que los archivos de log se colocarán en la <CATALINA_HOME> /, con el sufijo localhost_access_log, con el sufijo txt.

El atributo que me dio a mi el quebradero de cabeza era rotable, que en mi caso estaba a false y con esto hay que tener mucho cuidado. Por defecto está a true.

Escrito en Servidores de aplicaciones | Etiquetado accesslogvalve, log, Tomcat, valve | Deja un Comentario »

Ampliar la memoria al tomcat

16 Diciembre 2008

Uno de los problemas más comunes que nos hemos encontrado todos alguna vez es que nuestro servidor de aplicaciones, en este caso, tomcat, se quede sin memoria (heap space), para ampliarlo tenemos que tener en cuenta los parámetros que tenemos que modificar, cómo modificarlos y dónde modificarlos. Para empezar vamos a hablar de las opciones:

Maximum heap size: Esto indica el tamaño máximo de la memoria que usara la máquina virtual de java (JVM). En la mayoría de los casos el valor que toma por defecto es 64MB. Para ampliar la memoria se utiliza el parámetro -Xmx, por ejemplo, -Xmx512m. Hay que tener en cuenta que la memoria que se le aplique debe ser consiederablemente menor a la cantidad de RAM del sistema, sino puede entrar en conflicto con otras aplicaciones.

Nota:

Initial heap size: Indica el la memoria que se utiliza inicialmente y se configura de la siguiente usando el parámetro -Xms, por ejemplo, -Xms252m

Algunos de los fallos comunes a la hora de configurar la memoria del tomcat son:

No poner m, M o g, G, teniendo en cuenta que es sensible a mayúsculas.
Escribir mal la sentencia, no lleva espacios ni el símbolo “=”, la forma correcta es -Xmx512m.
Poner el initial heap size mayor que el maximun heap size.
Que se le haya asignado una memoría mayor que la real del sistema.
Usar como la unidad mb cuando es m.
Asignarle más memoria de la que la JVM piensa que va a ser necesaria.
No expresar la cantidad como un número entero.

Para modificar el tamaño de la memoria debemos ir a $TOMCAT_HOME\bin\catalina.sh o catalina.bat y poner:
set CATALINA_OPTS=”-Xms512m -Xmx512m” (Windows)
export CATALINA_OPTS=”-Xms512m -Xmx512m” (linux)

viernes, diciembre 03, 2010

En Resumen un Almacen de Datos(DataWareHouse) es

La ventaja principal de este tipo de sistemas se basa en su concepto fundamental, la estructura de la información
Integrado: los datos almacenados en el Data Warehouse deben integrarse en una estructura consistente, por lo que las inconsistencias existentes entre los diversos sistemas operacionales deben ser eliminadas. La información suele estructurarse también en distintos niveles de detalle para adecuarse a las distintas necesidades de los usuarios.
Temático: sólo los datos necesarios para el proceso de generación del conocimiento del negocio se integran desde el entorno operacional. Los datos se organizan por temas para facilitar su acceso y entendimiento por parte de los usuarios finales. Por ejemplo, todos los datos sobre clientes pueden ser consolidados en una única tabla del Data Warehouse. De esta forma, las peticiones de información sobre clientes serán más fáciles de responder dado que toda la información reside en el mismo lugar.
Histórico: el tiempo es parte implícita de la información contenida en un Data Warehouse. En los sistemas operacionales, los datos siempre reflejan el estado de la actividad del negocio en el momento presente. Por el contrario, la información almacenada en el Data Warehouse sirve, entre otras cosas, para realizar análisis de tendencias. Por lo tanto, el Data Warehouse se carga con los distintos valores que toma una variable en el tiempo para permitir comparaciones.
No volátil: el almacén de información de un Data Warehouse existe para ser leído, y no modificado. La información es por tanto permanente, significando la actualización del Data Warehouse la incorporación de los últimos valores que tomaron las distintas variables contenidas en él sin ningún tipo de acción sobre lo que ya existía.

Para comprender el concepto de Data Warehouse, es importante considerar los procesos que lo conforman. A continuación se describen dichos procesos clave en la gestión de un Data Warehouse:
Extraccion: obtención de información de las distintas fuentes tanto internas como externas.
Elaboracion: filtrado, limpieza, depuración, homogeneización y agrupación de la información.
Carga: organización y actualización de los datos y los metadatos en la base de datos.
Explotacion: extracción y análisis de la información en los distintos niveles de agrupación.

3.4.COMPONENTES A TENER EN CUENTA A LA HORA DE CONSTRUIR UN DW

3.4.1.Hardware

3.4.2.-Software de almacenamiento (SGBD)

3.4.3.- Software de extracción y manipulación de datos

• Control de la extracción de los datos y su automatización, disminuyendo el tiempo empleado en el descubrimiento de procesos no documentados, minimizando el margen de error y permitiendo mayor flexibilidad.
• Acceso a diferentes tecnologías, haciendo un uso efectivo del hardware, software, datos y recursos humanos existentes.
• Proporcionar la gestión integrada del Data Warehouse y los Data Marts existentes, integrando la extracción, transformación y carga para la construcción del Data Warehouse corporativo y de los Data Marts.
• Uso de la arquitectura de metadatos, facilitando la definición de los objetos de negocio y las reglas de consolidación.
• Acceso a una gran variedad de fuentes de datos diferentes.
• Manejo de excepciones.
• Planificación, logs, interfaces a schedulers de terceros, que nos permitiran llevan una gestión de la planificación de todos los procesos necesarios para la carga del DW.
• Interfaz independiente de hardware.
• Soporte en la explotación del Data Warehouse.
A veces, no se suele prestar la suficiente atención a esta fase de la gestión del Data Warehouse, aun cuando supone una gran parte del esfuerzo en la construcción de un Data Warehouse. Existen multitud de herramientas disponibles en el mercado que automatizan parte del trabajo.

3.4.4.- Herramientas Middleware

• Por un lado herramientas Middleware, que provean conectividad entre entornos diferentes, para ayudar en la gestión del Data Warehouse.
• Por otro, analizadores y aceleradores de consultas, que permitan optimizar tiempos de respuestas en las necesidades analíticas, o de carga de los diferentes datos desde los sistemas operacionales hasta el Data Warehouse.
Las herramientas Middleware deben ser escalables siendo capaces de crecer conforme crece el Data Warehouse, sin problemas de volúmenes. Tambien deben ser flexibles y robustas, sin olvidarse de proporcionar un rendimiento adecuado. Estarán abiertas a todo tipos de entornos de almacenamiento de datos, tanto mediante estándares de facto (OLE, ODBC, etc.), como a los tipos de mercado más populares (DB2, Access, etc.). La conectividad, al menos en estándares de transporte (SNA LU6.2, DECnet, etc.) debe estar tambien asegurada.
Con el uso de estas herramientas de Middleware lograremos:
• Maximizar los recursos ejecutando las aplicaciones en la plataforma más adecuada.
• Integrar los datos y aplicaciones existentes en una plataforma distribuida.
• Automatizar la distribución de datos y aplicaciones desde un sistema centralizado.
• Reducir tráfico en la red, balanceando los niveles de cliente servidor (mas o menos datos en local, mas o menos proceso en local).
• Explotar las capacidades de sistemas remotos sin tener que aprender multiples entornos operativos.
• Asegurar la escalabilidad del sistema.
• Desarrollar aplicaciones en local y explotarlas en el servidor.
Los analizadores y aceleradores de querys trabajan volcando sobre un fichero de log las consultas ejecutadas y datos asociados a las mismas (tiempo de respuesta, tablas accedidas, método de acceso, etc). Este log se analiza, bien automáticamente o mediante la supervisión del administrador de datos, para mejorar los tiempos de accesos.
Estos sistemas de monitorización se pueden implementar en un entorno separado de pruebas, o en el entorno real. Si se ejecutan sobre un entorno de pruebas, el rendimiento del entorno real no se vé afectado. Sin embargo, no es posible optimizar los esfuerzos, puesto que los análisis efectuados pueden realizarse sobre consultas no críticas o no frecuentemente realizadas por los usuarios.
El implantar un sistema analizador de consultas, en el entorno real tiene además una serie de ventajas tales como:
• Se pueden monitorizar los tiempos de respuesta del entorno real.
• Se pueden implantar mecanismos de optimización de las consultas, reduciendo la carga del sistema.
• Se puede imputar costes a los usuarios por el coste del Data Warehouse.
• Se pueden implantar mecanismos de bloqueo para las consultas que vayan a implicar un tiempo de respuesta excesivo.

3.4.5.Conclusiones y consideraciones de interes.

El Data Warehouse va a ser el elemento principal en nuestro sistema de Inteligencia de Negocio. De su correcta definición, procesamiento y carga de datos va a depender el exito posterior del proyecto.
Aunque el usuario al final solo vea un conjunto de herramientas de analisis que utilizar para “atacar” a los datos, por delante hay una serie de procesos que hacen que toda la información proveniente de diferentes sistemas haya sido identificada, extraida, procesada, homogeneizada, depurada y cargada en el Datawarehouse. Esto es posible a través de las herramientas ETL y Middleware. Y esta es la parte que normalmente mas tiempo lleva en cualquier proyecto.
Muchas veces conviene elegir un departamento piloto para implantar sistemas de este tipo que luego nos permitan vender internamente dentro de la organización los proyectos.
Habrá que dar siempre importancia a la formación como eje fundamental al uso de las herramientas.
Los proyectos de BI y DW no van a ser solo proyectos tecnológicos, hay mucho mas detras, y aunque en ellos se utilize la tecnología tiene que haber conocimiento empresarial para poder reflejar en el lo que realmente se necesita, desde los niveles mas bajos hasta los superiores de toma de decisiones. En este momento el consultor de BI también tiene que ser capaz de aportar no solo su conocimiento tecnológico, sino también conocimiento de las area de negocio y de los diferentes elementos que se van a utilizar en el diseño, desarrollo y explotación de un sistema de BI (ver el artículo de Jorge Fernández en su blog: El consultor de Bi, ese bicho raro ).

3.4.6. Nuevas tendencias en el mundo DW. El Datawarehouse 2.0.

Los sistemas DW han evolucionado en los ultimos años conforme han surgido nuevas necesidades. Los motivos de esta evolución son varios, y los podemos resumir en:
- Uso de herramientas de analisis que obligaban a estructuras diferentes optimazadas al uso de determinadas tecnologías (por ejemplo el data mining o el uso de herramientas estadísticas).
- Simplificación de la gestión de sistemas DW complejos formados por multiples datamarts orientados a cada departamento en los que se pierde el concepto de Corporativo (que hace que se pierdan oportunidades ).
- De la unión de multiples aplicaciones pequeñas (Datamarts o Datawarehouse), no surge toda la información corporativa. Sería necesario construir este Centro a partir del cual se van a generar todos los DW necesarios para todos los ambitos de análisis.
- Proceso Online: los procesos de actualización hacían que hubiera muchos momentos en los que no se podía acceder a los datos. Igualmente, podría haber cierto retardo en la disponibilidad de la información, lo que nos impedia poder hacer análisis inmediatos (analisis mas orientados a la operacion del negocio).
- Evolución tecnologica en las herramientas ETL, costes de la tecnología (los costes han bajando de tal forma que permiten abordar los proyectos de una forma mas amplia), etc.

jueves, diciembre 02, 2010

Cómo no construir un datawarehouse

Tomado de:
Creando un DW

A través de TodoBI he encontrado un artículo muy interesante de Ralph Kimball (¿Algún despistado que no lo conoce?) donde detalla los 12 errores más comunes en la construcción de un datawarehouse.
Se trata de un artículo excelente. Cada vez que he cometido alguno de estos errores, he tenido que rectificar al poco tiempo. No valen los atajos, hay que hacer las cosas bien desde el principio.
Los doce errores más comunes en la construcción de un datawarehouse son:

Error 12: Incluir atributos de texto en una tabla de hechos, si se hace con la intención de filtrar o agrupar.
Error 11: Abreviar las descripciones en las tablas de dimensión con la intención de reducir el espacio requerido.
Error 10: Dividir las jerarquías y los niveles de las jerarquías en múltiples dimensiones.
Error 9: No afrontar el tratamiento de las dimensiones lentamente cambiantes.
Error 8: Crear “smart keys” para relacionar una tabla de dimension con una tabla de hechos.
Error 7: Añadir dimensiones en una tabla de hechos antes de definir su granularidad.
Error 6: Crear un modelo dimensional para resolver un informe en particular.
Error 5: Mezclar hechos de diferente granularidad en una misma tabla de hechos.
Error 4: Olvidarse del máximo nivel de detalle en el modelo entidad-relación.
Error 3: Omitir las tablas agregadas y comprimir las tablas de dimension para afrontar los problemas de rendimiento.
Error 2: No unificar los hechos entre distintas tablas de hechos
Error 1: No compartir dimensiones entre diferentes tablas de hechos.

En mi vida laboral he participado en la construcción de varios datawarehouses, y he visto muchos de estos errores. Durante los próximos días, analizaré una a una estas recomendaciones de Kimball, e intentaré justificar por que son errores graves y cómo debemos evitarlos.
A mis lectores menos "tekies", os pido perdón porque los próximos mensajes no los escribo pensando en vosotros. Van dirigidos al lado oscuro... :-)

Serie sobre cómo construir un datawarehouse

Finalmente, he terminado de recorrer la lista de Ralph Kimball sobre cómo no construir un datawarehouse. A lo largo de estos artículos he intentado introducir los conceptos más importantes relativos a la modelización de un datawarehouse (base de cualquier entorno Business Intelligence).
Para finalizar esta serie, incluyo el índice de todas las entradas:

Introducción: Cómo no construir un datawarehouse
Artículo 1: Datawarehouse
Artículo 2: Dimensiones
Artículo 3: Jerarquías
Artículo 4: Dimensiones lentamente cambiantes
Artículo 5: Claves subrogadas
Artículo 6: Tablas de hecho
Artículo 7: DWH organizado por temas
Artículo 8: Tablas agregadas
Artículo 9: Máximo nivel de detalle
Artículo 10: Rendimiento
Artículo 11: Unificar los hechos
Artículo 12: Unificar las dimensiones

Cada artículo, analiza uno de los 12 errores que justificaron esta serie:

Mistake 12: Place text attributes in a fact table if you mean to use them as the basis of constraining and grouping.
Mistake 11: Limit the use of verbose descriptive attributes in dimensions to save space.
Mistake 10: Split hierarchies and hierarchy levels into multiple dimensions.
Mistake 9: Delay dealing with a slowly changing dimension (SCD).
Mistake 8: Use smart keys to join a dimension table to a fact table.
Mistake 7: Add dimensions to a fact table before declaring its grain.
Mistake 6: Declare that a dimensional model is "based on a specific report."
Mistake 5: Mix facts of differing grain in the same fact table.
Mistake 4: Leave lowest-level atomic data in E/R format.
Mistake 3: Eschew aggregate fact tables and shrunken dimension tables when faced with query performance concerns
Mistake 2: Fail to conform facts across separate fact tables.
Mistake 1: Fail to conform dimensions across separate fact tables.

Y que traduje de esta manera...

Error 12: Incluir atributos de texto en una tabla de hechos, si se hace con la intención de filtrar o agrupar.
Error 11: Abreviar las descripciones en las tablas de dimensión con la intención de reducir el espacio requerido.
Error 10: Dividir las jerarquías y los niveles de las jerarquías en múltiples dimensiones.
Error 9: No afrontar el tratamiento de las dimensiones lentamente cambiantes.
Error 8: Crear "smart keys" para relacionar una tabla de dimension con una tabla de hechos.
Error 7: Añadir dimensiones en una tabla de hechos antes de definir su granularidad.
Error 6: Crear un modelo dimensional para resolver un informe en particular.
Error 5: Mezclar hechos de diferente granularidad en una misma tabla de hechos.
Error 4: Olvidarse del máximo nivel de detalle en el modelo entidad-relación.
Error 3: Omitir las tablas agregadas y comprimir las tablas de dimension para afrontar los problemas de rendimiento.
Error 2: No unificar los hechos entre distintas tablas de hechos
Error 1: No compartir dimensiones entre diferentes tablas de hechos.

lunes, noviembre 29, 2010

Instalando JBOSS en Centos - Actualizado

Tomado de:
Instalar JBoss en Centos Instalar Jboss en Centos

Hace mucho tiempo que venía escuchando sobre Jboss, pero mi interés solo era de conocer, para que servía y que se podía hacer con el, pues bien, por motivos laborales tuve que retomar lecturas, definiciones sobre Jboss, no comentaré que es, y para que sirve, lo que leerán aquí es la instalación y algunos tips sobre la instalación, pues bien empecemos ... Para realizar la instalación, esta será usando centOS, también puede usarse en RHEL u OpenSuse.
Disco duro de 120Gb, 2Gb Ram, y CPU Core 2 Duo 2.4Ghz, deben contar con acceso al usuario root

1.- Comprobamos la versión de Java
#java -version

2.- Si tenemos algún mensaje en consola por ejm. "java version 1.4" está bien, pero sino, es igual, ya que usaremos la versión actual de Java para nuestra instalación.

Tip.- si desean borrar java, pueden ejecutar: yum remove java

3.- Nos dirigimos este enlace para descargar la última versión de java. Tip. Descargen JDK 6u21 o la que sea la más actual, y a su vez pueden escoger la plataforma que deseen, i386 o x86_64 y en el formaro "rpm.bin"

4.- Una vez descargado ejecutamos:
#chmod 755 jdk-6u21-linux-i386-rpm.bin

5.- Ahora ejecutamos:
#./jdk-6u21-linux-i386-rpm.bin

6.- Ejecutamos lo siguiente para saber la versión de java:
#java -version

7.- Creamos la carpeta "java" en el directorio opt:
#mkdir -p /opt/java

8.- Realizamos un enlace simbólico al directorio java:
#ln -s /usr/java/jdk1.6.0_21 /opt/java

9.- Crearemos un fichero ejecutable, en el indicaremos el "JAVA_HOME" que es muy importante para nuestra instalación, este "script" estará en la ruta /etc/profile.d:
#vim /etc/profile.d/java.sh
- - - -
#java
JAVA_HOME=/opt/java/jdk
PATH=$PATH:$JAVA_HOME/bin
CLASSPATH=$JAVA_HOME/lib LD_LIBRARY_PATH=$JAVA_HOME/jre/lib/i386
export JAVA_HOME PATH CLASSPATH LD_LIBRARY_PATH
- - - -

Tip. En LD_LIBRARY_PATH, deben de escoger si, por ejm. su server es X86_64, /lib/amd64

10.- Ahora damos permisos de ejecución al script y lo ejecutamos:
#chmod 755 /etc/profile.d/java.sh #sh /etc/profile.d/java.sh

11.- Ahora que tenemos java configurado, procedemos a instalar Jboss.

12.- Procedemos a descargar Jboss de este enlace yo, he descargado la version 4.3, el método de instalación funciona para cualquiera de las versiones.

13.- Descomprimimos Jboss:
#unzip jboss-4-0.3.GA-jdsk6.zip -d /usr/java

14.- Creamos un enlace simbólico:
#ln -s /usr/java/jboss-4.0.3.GA /opt/java/jboss

15.- Creamos el script "jboss.sh" en la ruta /etc/profile.d/
# vim /etc/profile.d/jboss.sh
- - -
# JBoss As
JBOSS_HOME=/opt/java/jboss
PATH=$PATH:$JBOSS_HOME/bin
export JBOSS_HOME PATH
- - -
16.- Damos permisos de ejecución y ejecutamos el script:
#chmod 755 /etc/profile.d/jboss.sh #sh /etc/profile.d/jboss.sh

17.- Agregamos el usuario "jboss"
#adduser jboss o useradd jboss

18.- Cambiamos permisos en la carpeta "jboss":
#chown -Rf jboss.jboss /opt/java/jboss/

19.- Ingresamos con el user "jboss":
#su jboss

20.- Ahora ejecutaremos el "run.sh", script por default que inicia los servicios para Jboss: $/opt/java/jboss/bin/run.sh

21.- Ahora, si queremos que escuche cualquier ip:
$/opt/java/jboss/bin/run.sh -b 0.0.0.0 (Tiene que digitar 0.0.0.0, con esto publica a toda la red)

22.- Si revisamos el log, veremos un mensaje así:
18:23:18,035 INFO [ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] Started in 1m:15s:48

23.- Para ingresar al panel de Jboss, desde nuesto browser: http://ip_server:8080

Espero que les sea de utilidad, y para la próxima, escribiré como crear instancias, definir proyectos bajo instancias y más.

Si usas JBoss desde consola debes modificar el archivo run.bat o run.sh, encontrarás en el script una parte que dice:

"%JAVA%" %JAVA_OPTS% ^
   -Djava.endorsed.dirs="%JBOSS_ENDORSED_DIRS%" ^
   -classpath "%JBOSS_CLASSPATH%" ^
   org.jboss.Main %*

Debe modificarse a:

"%JAVA%" %JAVA_OPTS% ^
   -Djava.endorsed.dirs="%JBOSS_ENDORSED_DIRS%" ^
   -classpath "%JBOSS_CLASSPATH%" ^
   org.jboss.Main -b0.0.0.0 %*

(El 0.0.0.0 puede ser modificado si deseas colocar una IP específica)
Otra forma es iniciarlo desde la línea de comandos pasando el parámetro:

run -b 0.0.0.0

El objetivo de este manual es explicar breve y básicamente la estructura de este servidor de aplicaciones.

Hay que aclarar que esta descripción es igual para Linux que para Windows.

El Jboss escucha por defecto en el puerto 8080.

El servidor de aplicaciones Jboss es libre y puede descargarse de la pagina oficial de la comunidad

http://www.jboss.org/community

Una vez descargado y descomprimido o instalado, analizaremos los directorios mas importantes.

Bajo la carpeta principal JBOSSX.X.X, se crearan los siguientes directorios

BIN
CLIENT
LIB
LICENSES
SCRIPT
SERVER

Los que mas usaremos serán BIN y SERVER. En ellos se alojarán los archivos ejecutables y nuestras aplicaciones, respectivamente.

EL DIRECTORIO BIN

Aquí se encuentran los ejecutables y los ficheros de configuración de la aplicación.

Los más importantes son:

JBOSS_INIT_REDHAT y JBOSS_INIT_SUSE: son scripts muy básicos para convertir nuestro Jboss en un daemon (servicio). Estos ficheros son exclusivos de Linux y sirven (como su nombre indica) para distros RedHat o Suse respectivamente.
RUN.BAT: Es el ejecutable por excelencia. Sirve para levantar nuestro Jboss en Windows.

Este fichero se puede editar (como todos los punto BAT) para modificar la ubicación de nuestra maquina JAVA por ejemplo. Otra linea para modificar muy importante es la siguiente:

set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx512m -server -XX +UseConcMarkSweepGC -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000

En esta linea, podemos configurar cuanta memoria reservaremos para el servidor. -Xms indicara el valor mínimo. -Xmx, el máximo.

RUN.SH: es el ejecutable por excelencia, pero de los sistemas Linux. Sirve para levantar nuestro Jboss. A diferencia de Windows, en este archivo no se puede modificar la cantidad reservada de memoria para la aplicación. Este archivo apunta a otro para coger la configuración. Este archivo se llama RUN.CONF
RUN.CONF: este archivo contiene las opciones de las que leerá el RUN.SH para arrancar Jboss. Es exclusivo de Linux.
RUN.JAR: es el ejecutable para Java.
SHUTDOWN.BAT: Sirve para detener nuestro servidor Jboss en Windows.
SHUTDOWN.SH: Sirve para detener nuestro servidor Jboss en Linux.

Si no hay errores, al ejecutar RUN.BAT (Windows) o RUN.SH (Linux) podremos acceder al Jboss, poniendo en un navegador la dirección IP donde esta instalado el servidor con el puerto 8080.

Por ejemplo http://localhost:8080. Si todo es correcto aparecerá la siguiente pantalla:

EL DIRECTORIO SERVER

Para empezar nos encontraremos con 3 carpetas (MINIMAL, ALL, DEFAULT) cada carpeta cargara mas o menos servicios al ejecutar el Jboss. Cuanto mas servicios por defecto mas memoria consumirá nuestro servidor de aplicaciones.

La parte que explicaremos es la de DEFAULT, aunque también es valida para las otras 2 opciones.

Dentro de la carpeta DEFAULT, encontraremos los siguientes directorios:

CONF
DEPLOY: Este directorio es el mas importante, ya que ahí se alojara nuestra aplicación. Esta puede ser un archivo .WAR, .SAR, etc. El Jboss cargará todas las aplicaciones que copiemos aquí.
LIB: las librerías del Jboss.
LOG: aquí se encuentran dos archivos.

BOOT.LOG: Es un archivo de texto plano, donde registra todas las incidencias producidas al inicio del Jboss.
SERVER.LOG: Es un archivo de texto plano, donde registra todas las incidencias producidas por el servidor de aplicaciones, incluido los errores producidos por nuestra aplicación. Este fichero “rota” diariamente generando ficheros con el siguiente formato server.log.2009-x-x con los logs de días anteriores. Hay que controlar estos archivos, ya que suelen ser muy pesados y si no los borramos pueden saturar en pocos días nuestro disco duro.

TMP: archivos temporales.
WORK: mas archivos temporales.

Aumentar el tamaño de memoria de la máquina virtual en Java

Submitted by avali2 on Sáb, 02/07/2009 - 12:56

Java Standard Edition

En Java, hay varios parámetros para controlar el tamaño inicial y el tamaño máximo que puede tomar la máquina virtual.
Además, hay que tener en cuenta el tipo de memoria sobre el que se quiere actuar: heap, non-heap (PermGen). Los valores por defecto que se dan corresponden a máquina virtuales de Sun, y son orientativos, porque pueden cambiar entre versiones de la máquina virtual. Los parámetros son los siguientes, fijándose a 128Mb.
* -Xms128m: Tamaño de inicio de la máquina virtual de Java a 128Mb. El valor por defecto son 64Mb. Si se aumenta este valor, se elimina el tiempo que se tardaría en aumentar el tamaño en memoria de la máquina virtual si se llegara el caso de que se necesitara más memoria, por lo que aumentaría el rendimiento en los casos que la aplicación haga uso intensivo de la memoria.
* -Xmx128m: Tamaño máximo de la máquina virtual de Java a 128Mb. El valor por defecto son 128Mb. Si la aplicación supera el tamaño máximo de memoria que marca este parámetro, se lanza la excepción java.lang.OutOfMemoryError. No conviene asignar a este parámetro el máximo de la memoria de la máquina porque si ya no queda memoria física disponible (por la que usa el sistema operativo u otras aplicaciones) se pueden producir escrituras en memoria asignada a otros programas y provocar un auténtico lío.
* -XX:PermSize=128m: Tamaño de inicio de la memoria de tipo PermGen a 128Mb. Arrancar la máquina virtual con un valor superior al por defecto agiliza la carga de aplicaciones, sobre todo en el caso de aplicaciones que hagan uso intensivo de este tipo de memoria (Spring, Hibernate…)
* -XX:MaxPermSize=128m: Tamaño máximo de la memoria de tipo PermGen a 128Mb. El valor por defecto son 64Mb. Si la aplicación supera el tamaño máximo de memoria para este tipo que marca este parámetro, se lanza la excepción java.lang.OutOfMemoryError: PermGen space. El valor necesario para este parámetro siempre suele ser menor que el de la memoria de tipo heap.
Si se quiere especificar un valor distinto de 128Mb, que se utiliza para todos los parámetros como ejemplo para simplificar, bastaría con sustituir el valor 128 del parámetro con el que se desee, siempre que sean múltiplos de 2 (64, 128, 256, 512, 768, 1024, 2048…)
Conocidos los tipos de memoria y los parámetros que los controlan, ahora viene la pregunta, ¿cómo especifico estos valores para mi aplicación? La respuesta es la misma para todos los casos: Los valores se especifican como parámetros en el arranque de la máquina virtual que ejecutará la aplicación. La diferencia estribará en cómo se arranca la aplicación: con un script, desde línea de comandos, mediante ant…
A continuación se dan distintos ejemplos de modificación de la memoria de distinta forma. No es necesario especificar todos los parámetros, se pueden especificar todos o ninguno (y se tomarían los valores por defecto)
Línea de comandos
* Ejecución de un jar: java -Xms128m -Xmx1024m -XX:PermSize=128m -XX:MaxPermSize=256m -jar example.jar
* Ejecución de una clase: java -Xms128m -Xmx1024m -XX:PermSize=128m -XX:MaxPermSize=256m com.programacionenjava.examples.MemoryExample
Ant
Script
Si el arranque de la máquina virtual se produce en un script, hay que editar el script y añadir estos parámetros en la sentencia de arranque. El siguiente ejemplo muestra cómo añadir estos parámetros en el script de arranque de un Tomcat.
* En Windows: set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=256m

* En Linux: JAVA_OPTS=”$JAVA_OPTS -Xms128m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=256m”

Por último, recordamos que resolver el problema de una excepción de tipo java.lang.OutOfMemoryError simplemente aumentando el tamaño de la memoria virtual puede retrasar el problema pero no evitarlo si el problema es una fuga de memoria. Puedes encontrar más información aquí.
Tomado de

Script para subir, bajar y Reiniciar un JBoss

Tomado de: Script JBOSS
Vamos a crear un script completo que permite subir, bajar y reiniciar un JBoss sobre Kubuntu 10.10.

Las opciones de branches, trunk es para subir (si esta arriba lo baja y publica un aplicativo) desde la copia de trabajo del subversion.

Creamos el archivo que contendrá el script: sudo vi /etc/init.d/jboss

Copia este contenido:

#! /bin/sh
#
# $Id: jboss_init_redhat.sh 71252 2008-03-25 17:52:00Z dbhole $
#
# JBoss Control Script
#
# To use this script run it as root - it will switch to the specified user
#
# Here is a little (and extremely primitive) startup/shutdown script
# for RedHat systems. It assumes that JBoss lives in /usr/local/jboss,
# it's run by user 'jboss' and JDK binaries are in /usr/local/jdk/bin.
# All this can be changed in the script itself.
#
# Either modify this script for your requirements or just ensure that
# the following variables are set correctly before calling the script.

# Init script modified for Ubuntu Server 8.04 by
# Chiral Software, Inc.

#define where jboss is - this is the directory containing directories log, bin, conf etc
JBOSS_HOME=${JBOSS_HOME:-"/RUTA/JBOSS/jboss-5.1.0.GA"}

#define the user under which jboss will run, or use 'RUNASIS' to run as the current user
#JBOSS_USER=${JBOSS_USER:-"jboss"}
JBOSS_USER=${JBOSS_USER:-"RUNASIS"}

#make sure java is in your path
#this must be set even if java is in a well-known place like /usr/bin
#JAVAPTH=${JAVAPTH:-"/RUTA/java/jdk1.6.0_22"}

#configuration to use, usually one of 'minimal', 'default', 'all'
JBOSS_CONF=${JBOSS_CONF:-"default"}

#if JBOSS_HOST specified, use -b to bind jboss services to that address
# JBOSS_BIND_ADDR=${JBOSS_HOST:+"-b $JBOSS_HOST"}
#JBOSS_BIND_ADDR=${JBOSS_HOST:-"-b IP_DEL_EQUIPO"}

#define the script to use to start jboss
JBOSSSH=${JBOSSSH:-"$JBOSS_HOME/bin/run.sh -c $JBOSS_CONF $JBOSS_BIND_ADDR"}

#define la ruta de la ubicación del branches donde esta el codigo fuente
BRANCHES=${BRANCHES:-"/RUTA/2_Fuentes/branches/VERSION"}

#define la ruta de la ubicación del trunk donde esta el codigo fuente
TRUNK=${TRUNK:-"/RUTA/2_Fuentes/trunk"}

if [ "$JBOSS_USER" = "RUNASIS" ]; then
  SUBIT=""
else
  SUBIT="su - $JBOSS_USER -c "
fi

if [ -n "$JBOSS_CONSOLE" -a ! -d "$JBOSS_CONSOLE" ]; then
  # ensure the file exists   touch $JBOSS_CONSOLE   if [ ! -z "$SUBIT" ]; then    chown $JBOSS_USER $JBOSS_CONSOLE   fi
fi

if [ -n "$JBOSS_CONSOLE" -a ! -f "$JBOSS_CONSOLE" ]; then
  echo "WARNING: location for saving console log invalid: $JBOSS_CONSOLE"   echo "WARNING: ignoring it and using /dev/null"   JBOSS_CONSOLE="/dev/null"
fi

#define what will be done with the console log
JBOSS_CONSOLE=${JBOSS_CONSOLE:-"$JBOSS_HOME/server/$JBOSS_CONF/log/console.log"}

JBOSS_CMD_START="cd $JBOSS_HOME/bin; $JBOSSSH"

#if [ -z "`echo $PATH | grep $JAVAPTH`" ]; then
# export PATH=$PATH:$JAVAPTH
#fi

if [ ! -d "$JBOSS_HOME" ]; then
  echo JBOSS_HOME does not exist as a valid directory : $JBOSS_HOME   exit 1
fi

procrunning () {
   procid=0    for procid in `pidof -x $JBOSS_HOME/bin/run.sh`; do    ps -fp $procid | grep "${JBOSSSH% *}" > /dev/null && pid=$procid    done
}

stop () {
   pid=0    procrunning    if [ $pid = '0' ]; then    /bin/echo -n -e "\nNo JBossas is currently running\n"    exit 1    fi

   RETVAL=1

   # If process is still running

   # First, try to kill it nicely    for id in `ps --ppid $pid | awk '{print $1}' | grep -v "^PID$"`; do    if [ -z "$SUBIT" ]; then    kill -15 $id    else    $SUBIT "kill -15 $id"    fi    done

   sleep=0    while [ $sleep -lt 120 -a $RETVAL -eq 1 ]; do    /bin/echo -n -e "\nwaiting for JBoss processes to stop\n";    sleep 10    sleep=`expr $sleep + 10`    pid=0    procrunning    if [ $pid = '0' ]; then    RETVAL=0    fi    done

   count=0    pid=0    procrunning

   if [ $RETVAL != 0 ] ; then    /bin/echo -e "\nTimeout: Shutdown command was sent, but process is still running with PID $pid\n"    exit 1    fi

   echo    exit 0
}

case "$1" in
start)
   echo "Iniciando el JBoss"    eval touch $JBOSS_HOME/server/$JBOSS_CONF/log/server.log    cd $JBOSS_HOME/bin    if [ -z "$SUBIT" ]; then
# eval $JBOSS_CMD_START >${JBOSS_CONSOLE} 2>&1 &
   eval $JBOSS_CMD_START 2>&1 &    else
# $SUBIT "$JBOSS_CMD_START >${JBOSS_CONSOLE} 2>&1 &"
   $SUBIT "$JBOSS_CMD_START 2>&1 &"    fi    eval tail -f $JBOSS_HOME/server/$JBOSS_CONF/log/server.log    ;;
stop)
   stop    ;;
restart)
   $0 stop    $0 start    ;;
trunk)
   $0 stop    echo "Eliminando archivos existentes"    rm $JBOSS_HOME/server/$JBOSS_CONF/deploy/empaquetado.jar    rm $JBOSS_HOME/server/$JBOSS_CONF/deploy/empaquetado.war    rm $JBOSS_HOME/server/$JBOSS_CONF/lib/librerias_propias*.jar

   echo "Publicando nuevos archivos"    cp $TRUNK/RUTA/target/empaquetado.jar $JBOSS_HOME/server/$JBOSS_CONF/deploy/empaquetado.jar    cp $TRUNK/RUTA/target/empaquetado.war $JBOSS_HOME/server/$JBOSS_CONF/deploy/empaquetado.war

   $0 start    ;;
branches)
   $0 stop    echo "Eliminando archivos existentes"

rm $JBOSS_HOME/server/$JBOSS_CONF/deploy/empaquetado.jar

rm $JBOSS_HOME/server/$JBOSS_CONF/deploy/empaquetado.war

rm $JBOSS_HOME/server/$JBOSS_CONF/lib/librerias_propias*.jar

echo "Publicando nuevos archivos"

cp $BRANCHES/RUTA/target/empaquetado.jar $JBOSS_HOME/server/$JBOSS_CONF/deploy/empaquetado.jar

cp $BRANCHES/RUTA/target/empaquetado.war $JBOSS_HOME/server/$JBOSS_CONF/deploy/empaquetado.war

   $0 start
   ;;
*)
   echo "usage: $0 (start|stop|restart|branches|trunk|help)"
esac

Terminando de pegar el contenido del script, lo guarda dando ESC :wq

Ya tenemos el script, ahora es solo darle permisos de ejecución: sudo chmod 755 jboss

Y listo, ya lo podemos ejecutar: service jboss aplicacion

Con esto debería subir el JBoss realizando la publicación de nuestro aplicativo que esta en el aplicacion del repositorio.

Tomado de: Jboss basico

JBoss básico funcionando en pocos pasos

1. Instalación
2. Arrancar y parar el servidor
3. Desplegar una aplicación
4. Configurar una Base de Datos
5. Múltiples instancias del servidor
6. Conectividad Apache - JBoss (mod_jk2)
7. Seguridad extra

Para el caso nos vamos a centrar en la versión 4.0.5GA que era la última versión estable a la hora de hacer la instalación. La máquina virtual es de Sun - JDK 1.6.0-b105. El sistema utilizado es un Debian Etch.

1. Instalación

Para la instalación he usado la guia oficial de JBoss.
Nos bajamos el servidor del site de JBoss, descomprimimos, ejecutamos

$ java -jar jems-installer-1.2.0.jar

y seguimos las instrucciones - idioma de la instalación, licencia, directorio de la instalación (apartir de ahora JBOSS_HOME) y los componentes. Aquí hay que tener cuidado - si vamos a usar EJB3, con clustering o no, tenemos que instalar Java5 porque EJB3 no es compatible con 1.4. Luego viene el nombre de la instancia (default en un principio nos sirve), configuración de la base de datos (seleccionad la vuestra), datasource por defecto y el usuario administrador. Aquí ponemos una contraseña y nos queda esperar hasta que el instalador termine su trabajo. Sencillo.
El instalador en linea de comandos no es mucho mas complicado.

Hemos terminado la instalación.

2. Arrancar y parar el servidor

En linea de comandos y como root creamos un usuario que va a ser el encargado de administrar el servidor :

$adduser jboss

El arranque del servidor lo hacemos en consola :

$JBOSS_HOME/bin/run.sh

Pararlo, igual :

$JBOSS_HOME/bin/shutdown.sh

Esto inicia y para el servidor, pero no nos va a servir. Para hacer las cosas bién tenemos que arrancar el servidor con nuestro usuario jboss :

su jboss -p -s /bin/sh -c "sh JBOSS_HOME/bin/run.sh"

Para pararlo - lo mismo pero con shutdown.
Como shell del usuario he puesto /bin/sh. Vosotros poned el vuestro favorito.
Ahora está bién. Pero, claro, la consola donde hemos tecleado esto está ocupada e inservible, y, además, cada vez que arrancamos nuestro sistema temenos que iniciar el servidor a mano ... incomodo.
Nos preparamos un script de inicio, lo colocamos en /etc/init.d y hacemos los links necesarios. Así la próxima vez que iniciemos nuestro sistema se iniciará el servidor.
Para cosas sencillas yo utilizo nano, vosotros - vuestro preferido.

$nano /etc/init.d/jboss

#!/bin/sh
# /etc/init.d/jboss: Start and stop JBoss AS

TEST=/usr/bin/test

JBOSS_HOME=${JBOSS_HOME:-"/donde/este/vuestro/jboss/jboss-4.0.5.GA"}
JBOSS_HOST=${JBOSS_HOST:-"0.0.0.0"}
JAVAPTH=${JAVAPTH:-"/opt/jdk1.6.0/bin"}

JBOSS_START_SCRIPT=$JBOSS_HOME/bin/run.sh
JBOSS_STOP_SCRIPT=$JBOSS_HOME/bin/shutdown.sh

OPT="-b $JBOSS_HOST"

JBOSS_USER=jboss

if [ `id -u` -ne 0 ]; then
   echo "Not starting/stopping JBoss, you are not root."
   exit 4
fi

$TEST -x $JBOSS_START_SCRIPT || exit 0
$TEST -x $JBOSS_STOP_SCRIPT || exit 0

start() {
   echo -e "Starting JBoss ...\n"
   export PATH=$PATH:$JAVAPTH

   chown -R $JBOSS_USER $JBOSS_HOME
   cd $JBOSS_HOME/bin

   su $JBOSS_USER -p -s /bin/sh -c "sh $JBOSS_START_SCRIPT $OPT 2> /dev/null &"
}

stop() {
   echo -e "Stopping JBoss ...\n"
   su $JBOSS_USER -p -s /bin/sh -c "sh $JBOSS_STOP_SCRIPT -S &"
   wait
}

case "$1" in
   start)
      start
      ;;
   stop)
      stop
      sleep 20
      ;;
   restart)
      stop
      sleep 20
      start
      ;;
   *)
   echo -e "\nUsage: jboss {start|stop|restart}\n"
   exit 1
esac

exit 0

El parámetro -b indica la dirección IP donde escucha nuestro servidor. Ahora le hemos indicado que acepte todas las direcciones. En capítulo 5. Múltiples instancias del servidor este parámetro cobra mas sentido.

La tercera linea de la función start() la podeis eliminar. Eso sí, el comando hay que ejecutarlo en consola y como root por lo menos una vez después de la instalación. Si no lo haceis vais a recibir un mensaje muy bonito de tipo :

ERROR [MainDeployer] Could not make local copy for file:/JBOSS_HOME/server/default/conf/jboss-service.xml java.io.FileNotFoundException: /JBOSS_HOME/server/default/tmp/deploy/server/default/conf/jboss-service.xml/1.jboss-service.xml (Permission denied)

Ya tenemos el script. Lo linkamos en /etc/rc5 como :

$ln -s S55jboss /etc/init.d/jboss

y en rc.0 :

$ln -s K15jboss /etc/ini.d/jboss

Lo mismo en los demás runlevels pero siempre teniendo cuidado - el jboss tiene que iniciarse antes que el apache y pararse antes que vuestra base de datos.

Parece que hemos completado el arranque.

3. Desplegar una aplicación

Después de preparar una aplicación y empaquetarla (como hacer esto no es nuestro objetivo por ahora), lo único que tenemos que hacer para desplegarla es copiarla en el directorio JBOSS_HOME/server/default/deploy del sitio de la compilación.

Para hacer el undeploy - borrarla del dicho directorio. Si no quereis borrar, preparad un directorio, por ejemplo undeploy, y simplemente copiad el fichero de la aplicación de .../deploy a .../undeploy.

Estas operaciones hay que hacerlas como root - acordaos que JBOSS_HOME es del usuario jboss. Si lo intentamos como un usuario normal no vamos a tener permisos.
Otra opción sería hacer un link (sí, como root) hacia el directorio donde teneis los proyectos.

Ya sabemos como desplegar aplicaciones.

4. Configurar una Base de Datos

Por defecto la Base de Datos que viene configurada con JBoss es HSQLDB (Hypersonic), así que ya la tenemos. Ahora nos falta la que queremos usar con nuestras aplicaciones. Nos centramos en MySQL. Es la que mas facil instalamos en nuestro sistema y la que uso habitualmente. Bueno, he probado también Oracle y SQL Server (esta última casi mejor no mencionarla) pero como son gestores de BD propietarios, los vamos a dejar por ahora.

Vamos allá.

Primero nos hacemos con el driver de la Base de Datos mysql-connector-java-3.0.9-stable-bin.jar y lo copiamos en JBOSS_HOME/server/default/lib.
También copiamos /docs/examples/jca/mysql-ds.xml a JBOSS_HOME/server/default/deploy y lo modificamos - en la etiqueta <driver-class/> ponemos com.mysql.jdbc.Driver y en <connection-url/> colocamos jdbc:mysql://<host_mysql>/<nombre_base_datos>.

Abrimos standardjaws.xml o jaws.xml y modificamos <datasource> and <type-mapping> como sigue :

<jaws>
<datasource>java:/MySqlDS</datasource>
<type-mapping>mySQL</type-mapping>
</jaws>

También tenemos que arreglar <datasource> y <type-mapping> en standardjbosscmp-jdbc.xml (o jbosscmp-jdbc.xml) :

<jbosscmp-jdbc>
   <defaults>
      <datasource>java:/MySqlDS</datasource>
      <datasource-mapping>mySQL</datasource-mapping>
   </defaults>
</jbosscmp-jdbc>

Ya queda poco. Modificamos login-config.xml añadiendo el tag <application-policy/> con la configuración de nuestra Base de Datos :

<application-policy name = "MySqlDbRealm">
   <authentication>
      <login-module code = "org.jboss.resource.security.ConfiguredIdentityLoginModule" flag = "required">
         <module-option name ="principal">NOMBRE_BASE_DATOS</module-option>
         <module-option name ="userName">USUARIO_BASE_DATOS</module-option>
         <module-option name ="password">PASSWORD_BASE_DATOS</module-option>
         <module-option name ="managedConnectionFactoryName">
            jboss.jca:service=LocalTxCM,name=MySqlDS
         </module-option>
      </login-module>
   </authentication>
</application-policy>

Listo.

5. Múltiples instancias del servidor

Pocas razones, excepto pruebas, se me ocurren para querer iniciar mas de una instancia del servidor.
Una, con algo de sentido, sería que montando un hosting, uno de los clientes exije una máquina virtual que no es la que ya teneis instalada.
Podría darse el caso que quereis ejecutar EJB3 pero las aplicaciones que ya teneis hechas corren mejor en JVM 1.4 (por ejemplo) o simplemente no os la quereis jugar a la ruleta rusa mudando una aplicación a otra máquina virtual. Entonces os haceis con dos instancias - una con JVM 1.4 para las aplicaciones "antiguas" y otra con 1.5 (os acordais ¿verdad?) para los EJB3.

Creando otra instancia.

Lo primero es crear dos configuraciones para las instancias. Así que copiamos nuestra configuración por defecto a, por ejemplo, instancia2 :

$cp JBOSS_HOME/server/default/* JBOSS_HOME/server/instancia2/

Si iniciamos la segunda instancia recibiremos un conflicto en puertos de escucha, así que vamos cambiando. Añadiremos un "1" delante en todos los puertos del servidor.
Los ficheros y puertos a retocar en JBOSS_HOME/server/instancia2 son los siguientes :

deploy/jbossweb-tomcat55.sar/server.xml: 8080 -> 18080
conf/jboss-service.xml: 1099 -> 11099; 1098 -> 11098; 4445 -> 14445; 4444 -> 14444; 8083 -> 18083
conf/jboss-minimal.xml: 1099 -> 11099; 1098 -> 11098
deploy/jms/uil2-service.xml: 8093 -> 18093

Nos queda iniciar las instancias. Usamos opción -c : $JBOSS_HOME/bin/run.sh -c instancia2 -b 192.168.1.18 (o -b instancia2.jboss_cluster.erFlako.net) Cambiando nombre y dirección de cada instancia. De la misma forma (con shutdown.sh) las paramos. Para evitar problemas es buena práctica añadir algún retardo en el arranque / parada de las instancias - unos 20 segundos es suficiente. Esto nos evitará conflictos en el servicio HA-JMS y ... en fin - a poner el retardo. Otra cosa hecha.

6. Conectividad Apache - JBoss (mod_jk2)

JBoss 4.0.5 trae Tomcat 5.5, así que la configuración no es muy diferente de un Tomcat cualquiera.
Las pequeñas diferencias las comentaremos aparte.

Suponiendo que ya tenemos Apache 2 y mod_jk1.2.x vamos directos a la configuración.
Los comentarios entre paréntesis se refieren a las peculiaridades de Debian.

6.1 Apache
Añadimos al final de APACHE_HOME/conf/apache2.conf (en Debian /etc/apache2.conf) :

Include conf/mod-jk.conf

Para los usuarios de Debian - simplemente linkar mod-jk.conf de sites-available a sites-enabled.

6.2. mod-jk
Creamos APACHE_HOME/conf/mod-jk.conf (Debian /etc/apache2/mods-available) :

# Cargar el modulo mod_jk
# Nombre de la librería mod_jk
LoadModule jk_module modules/mod_jk.so

# Sitio de workers.properties
JkWorkersFile conf/workers.properties

# Sitio de los logs de jk
JkLogFile logs/mod_jk.log

# Nivel de log [debug/error/info]
JkLogLevel info

# Formato de log
JkLogStampFormat "[%a %b %d %H:%M:%S %Y]"

# JkOptions
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories

# JkRequestLogFormat
JkRequestLogFormat "%w %V %T"

# Sitio de donde montar las aplicaciones
JkMount /aplicaciones_java/* loadbalancer

# Para indicar puntos de montaje se puede usar un fichero externo.
# Se actualiza cada 60 segundos.
# El formato es: /url=worker
# /ejemplos/*=loadbalancer
JkMountFile conf/uriworkermap.properties
# en mi caso (Debian) : # JkMountFile uriworkermap.properties

# Se puede añadir memoria compartida.
# A partir de versión 1.2.10 y posteriores de mod_jk.
# Necesario para el correcto funcionamiento del balanceo de carga.
JkShmFile logs/jk.shm

# Añadir jkstatus para manejar datos en tiempo de ejecución
<Location /jkstatus/>
   JkMount status
   Order deny,allow
   Deny from all
   Allow from 127.0.0.1
</Location>

6.3 workers.properties
En APACHE_HOME/conf/worker.properties o donde hemos indicado en jk.conf (yo lo tengo en /etc/apache2).

# Directivas validas para mod_jk 1.2.18 y posteriores

# Definimos la lista de workers a usar

worker.list=loadbalancer,status

# Definimos Nodo1
# Modificar el host con vuestra IP o nombre DNS
worker.node1.port=8009
worker.node1.host=test.er-flako.dyndns.org
worker.node1.type=ajp13
worker.node1.lbfactor=1
# worker.node1.connection_pool_size=10 (1)

# Definimos Nodo2
worker.node2.port=8009
worker.node2.host=pruebas.er-flako.dyndns.org
worker.node2.type=ajp13
worker.node2.lbfactor=1
# worker.node2.connection_pool_size=10 (1)

# Comportamiento del loadbalancer
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=node1,node2

# Un worker de estado para manejar el balanceo de carga
worker.status.type=status

En caso de duda con las directivas y la versión de mod-jk. consultar la completa lista de directivas.

Las dos lineas de connection_pool_size están comentadas porque connection_pool_size se indica solamente si el número de conexiones al servidor http es mayor que el maxThreads de server.xml.

Si indicamos worker.loadbalancer.sticky_session=Off, las peticiones serán balanceadas entre nodo1 y nodo2 con todo lo que esto conlleva - si un usuraio abre sesión en un servidor y el loadbalancer le envia al otro, el usuario perderá la sesión http. Así que si vais a usar balanceo de carga no podeis usar el objeto session para transportar datos entre la capa de negocio y la capa web. O sincronizar los datos entre las sesiones.
Es buena idea enviar un cliente siempre al mismo servidor.
Por defecto sticky_session está habilitado.

6.4 uriworkermap.properties
En APACHE_HOME/conf o directamente en /etc/apache2 :

# Ejemplo de configuración de workers

# Montamos el Servlet context con el ajp13 worker
/jmx-console=loadbalancer
/jmx-console/*=loadbalancer
/web-console=loadbalancer
/web-console/*=loadbalancer

# corresponde a node1 de worker.properties
/test=loadbalancer
/test/*=loadbalancer

# y node2
/pruebas=loadbalancer
/pruebas/*=loadbalancer

Tenemos nuestras consolas y los nodos que hemos definido redirigidas hacia el Tomcat.

6.5 Tomcat
En JBOSS_HOME/server/NOMBRE_DE_INSTANCIA/deploy/jbossweb-tomcat55.sar/server.xml (cambiamos NOMBRE_DE_INSTANCIA con el nombre de la instancia para cada caso) encontramos la etiqueta Engine y añadimos jvmRoute :

jvmRoute tiene que coincidir con el nombre especificado en worker.properties.

Aseguraos de que las lineas correspondientes al conector AJP 1.3 están descomentadas :

<Connector port="8009" address="${jboss.bind.address}"
         emptySessionPath="true" enableLookups="false" redirectPort="8443"
         protocol="AJP/1.3"/>

Si no quereis que Tomcat esté disponible através del puerto 8080, simplemente comentad las lineas correspondientes a la conexión tradicional.

Y por último decirle a Tomcat que añada el valor de jvmRoute a las cookies de sesión para que mod_jk pueda enrutar peticiones entrantes.
Editamos JBOSS_HOME/server/NOMBRE_DE_INSTANCIA/deploy/jbossweb-tomcat55.sar/META-INF/jboss-service.xml. Buscamos el atributo UseJK y lo ponemos a true :

<attribute name="UseJK">true</attribute>

Si al acceder a http://localhost/web-console veis la consola de JBoss, el trabajo está bien hecho.

Que lo disfruteis.

7. Seguridad extra

Esta parte del "tutorial" tiene algo que ver con la anterior - Conectividad Apache - JBoss (mod_jk2).
Por defecto JBoss inicia muchos servicios y cada servicio escucha un puerto.

1099        TCP     org.jboss.naming.NamingService
1098        TCP     org.jboss.naming.NamingService
1162        UDP     org.jboss.jmx.adaptor.snmp.trapd.TrapdService
4444        TCP     org.jboss.invocation.jrmp.server.JRMPInvoker
4445        TCP     org.jboss.invocation.pooled.server.PooledInvoker
8009        TCP     org.jboss.web.tomcat.tc4.EmbeddedTomcatService
8009        TCP     org.jboss.web.tomcat.tc4.EmbeddedTomcatService
8083        TCP     org.jboss.web.WebService
8090        TCP     org.jboss.web.OILServerILService
8092        TCP     org.jboss.mq.il.oil2.OIL2ServerILService
8093        TCP     org.jboss.mq.il.uil2.UILServerILService
anónimo TCP     org.jboss.mq.il.rmi.RMIServerILService
anónimo UDP     org.jboss.jmx.adaptor.snmp.agent.SnmpAgentService

Para impedir el acceso a estos servicios desde fuera de vuestra red local (o VPN) actualizamos la configuración de JBoss para que escuche solamente las direcciones locales y así prohibir el acceso a todos los puertos excepto 80.
En el script de inicio (2. Arrancar y parar el servidor) cambiamos JBOSS_HOST a 127.0.0.1. Ahora JBoss escucha solamente localhost.

Para acceder al servidor podemos crear un tunel através de ssh :
$ssh -L 8081:localhost:8080 vuestra_IP.
Ahora http://localhost:8081 nos lleva al puerto 8080 de nuestro JBoss.

Lo mismo si hemos configurado mod_jk y Apache - accedemos al puerto 80 y mod_jk nos lleva al 8080 de JBoss.

También se puede hacer un redireccionamiento usando iptables, pero esto impedirá tener un apache en el puerto 80.

De todas formas, usemos el método que usemos, hay que cerrar todos los puertos que no se utilizan en nuestro router y dejar abiertos solamente los necesarios para el funcionamiento de JBoss.