jueves, 16 de junio de 2011

miércoles, 15 de junio de 2011

Seguridad en JBoss EAP 5.0. Autenticacion, SSL, JAAS, LDAP

El servidor de aplicaciones puede usar las librerías del JBoss para autenticar al usuario, configurando donde se guardan las credenciales (una base datos o un directorio de usuarios o un archivo plano)
La seguridad en JBoss es declarativa por lo que declara en archivos XML antes que incluirlos en los componentes de negocio. La seguridad no se programa.
La autenticacion asigna la identidad del usuario. La autorizacion  asigna  permisos sobre los  recursos.
Para la autenticación el JBoss ha desarrollado varios modulos:
En el archivo /conf/login-config.xml se definen las políticas de autenticación.
<application-police>
<module />
</application-police>

El JBoss cuenta con una implementación estándar de la especificación JAAS (Java Autentication and Authorization Service). Todos los servidores de aplicaciones cuentan con una implementación de JAAS.
Los roles JBoss tienen accesos a componentes JSP o servlets, también se puede brindar accesos a un botón o un método. Los roles se les asigna a un grupo de usuarios.
En la aplicación se agrega un archivo jboss-web.xml para definir la política de autenticación. En login-config.xml se indica la política configurada en el jboss-web.xml de la aplicación. Los componentes EJB se configuran con el archivo ejb-jar.xml.
Se puede configurar  multiples dominios de seguridad, uno diferente para cada aplicación. Pero con un único dominio de seguridad, un usuario validado en una aplicación  puede conectarse a otra aplicación. Un dominio de seguridad tiene asociado un nombre único.

El LoginModule es la implementación de la autenticación del usuario y password, usualmente contra algún tipo de almacemiento de datos. El LoginModule asigna roles. Se configura un LoginModule por dominio de seguridad. El DatabaseServerLoginModule accede a una base de datos para autenticar el usuario y el password. Otro método de autenticación es usar un LDAP server.

En JBoss tambien se puede asegurar el acceso a los EJB, a las colas de mensajeria, y también los datasource.

Para asignar roles a un EJB se usa el descriptor de los componentes ejb-jar.xml  y también a través del mismo componente via anotaciones.

El SSL se configura en el deploy/jbossweb.sar/server.xml. El certificado se configura en el archivo jboss-web.xml. La seguridad JAAS también se puede acceder via JNDI.

El método de autenticación en JBoss para el login son: basic (formulario estandar del jboss), form (formulario definido por el programador), cert (con certificado digital), digest (con protocolo SSL).

 
Compartir:

Como aligerar los servicios del JBoss EAP 5.0

Se debe quitar del JBoss los elementos que no se van a usar. El aligeramiento se inicia con la configuracion "default" sino esta en cluster y con "all" si esta en cluster. La configuracion "production" tiene lo minimo, ni aparace el log en la consola. El estado de los parametros del servidor se pueden observar en el jmx-console.
Si se carga el mail al JBoss, en la consola se mostrará: [MailService] Mail Service bound to java:/Mail.
Si no se desea cargar el mail al JBoss se remueve el archivo mail-service.xml de la carpeta deploy y el JBoss informara:   [MailService] Mail service 'java:/Mail' removed from JNDI.
Para deshabilitar el conector AJP, se modifica en \deploy\jbossweb.sar comentando lo siguiente.
<!-- A AJP 1.3 Connector on port 8009
      <Connector protocol="AJP/1.3" port="8009" address="${jboss.bind.address}"
         redirectPort="8443" />
 -->
Para deshabilitar el servicio Messaging del JBoss se remueve la carpeta \deploy\messaging
Para deshabilitar el servicio Transaction del JBoss se remueve el archivo /deploy/transaction-service.xml
Compartir:

JNDI, mensajes y colas en JBoss EAP 5.0

El servicio JNDI se configura en el archivo conf/jboss-service.xml. Un servidor JBoss puede utilizar HTTP o HTTPS. En ambientes en cluster el JNDI puede estar disponible mediante HA-JNDI. Se conecta con la IP ${jboss.bind.address} que se muestra en los archivos de configuración.
En el servidor, el servicio JNDI se configura en el conf/jboss-service.xml. El JNDI naming service se configura mediante el archivo  jndi.properties en el cliente.
EL JNDI usa el puerto 1099. En JBoss se hace un tunel para acceder al servicio de manera remota (puede cruzar un firewall).
Properties p = new Properties();
p.put("java.naming.provider.url","...");
Context ctx = net Context(p)
Impuesto i =  (Impuesto) ctx.lookup("interes/remote");
double d = i.getInteres(8.2);
Otro servicio que provee JBoss es el servicio de mensajería que se maneja mediante colas. Los mensajes se utilizan entre aplicaciones generalmente mediante procesos asíncronos. La mensajería se usa cuando se tiene un sistema con alta demanda.
Las colas están configuradas en el  deploy/messaging/messaging-services.xml y en destination-services.xml. Otro archivo importante es *-persistente-service.xml si se desea que las colas se guarden en una base de datos. Para agregar o modificar una cola en JBoss se configura el archivo  deploy/messaging/destination-services.xml
Otros conectores que JBoss maneja son: remoting, RMI/JRMP. Permite acceder a los componentes EJB a través del puerto 4445. También permite realizar pedidos remotos vía sockets.
Compartir:

Como configurar varios nodos JBoss con la misma IP y diferente puerto?

El servicio ServiceBindingManager permite levantar varios nodos en el mismo hardware y con la misma IP. Si en el archivo de configuración, el offset es igual a 100 y el port del jboss es 8080, el port1 será 8180, el port2 será el 8280. De esta manera se levanta varios JBoss con la misma IP y diferente puertos
Para levantar cada uno de los nodos se realiza:
run.bat -c nodo1  -Djboss.service.binding.set=port1
run.bat -c nodo2  -Djboss.service.binding.set=port2
run.bat -c nodo3  -Djboss.service.binding.set=port3
No se recomienda usar el ServiceBindingmanager sobre direcciones virtuales, mucho mejor se realiza sobre IPs reales.
Compartir:

HTTP, HTTPS y AJP en JBoss Web Server EAP 5.0

La capa web se conoce como JBoss Web Server (jsp, jdni, webservice, servlets) y se puede licenciar por separado del JBoss EAP. Se basa en Apache-Tomcat. Soporta SSL. Puede balancear la carga mediante un Apache.
Los conectores web son HTTP1.1 (8080),  HTTPS (8443) y AJP1.3 (8009, Apache Java Protocol), este último se usa para conectarse a un balanceador de carga como Apache.
El servidor web de JBoss esta ubicado en la carpeta deploy/jbossweb.sar y la configuración del servidor esta en el archivo  deploy/jbossweb.sar/server.xml
Un Web Server como Apache se comunica con un Web Container como el JBoss mediante el protocolo AJP.
Los componentes web (JSP, servlets) se despliegan en un web container (Jboss Web).  Los componentes EBJ (session, entidad, MDB) se despliegan en un EJB container. Los componentes web se comunican con los componentes EJB  mediante el protocolo rmi.
Para que una plataforma diferente (como .NET) se comunique con el EJB container se requiere un WebService container que consuma los componentes del EJB container y lo tenga disponible para la otra plataforma.
El JBoss Web Engine puede contener multiples hosts. Un contexto en JBoss Web representa a una aplicacion web. Los tres principales conectores del JBoss Web son HTTP, HTTPS y AJP
El puerto pode defecto del AJP (Apache Java Protocol) es el 8009.  El JBoss Web Server se configura mediante el archivo /deploy/jbossweb.sar/server.xml
Compartir:

martes, 14 de junio de 2011

Como monitorear el JBoss EAP 5.0 JMX-console, admin-console

Las herramientas para monitorear el JBoss es el JMX-console, el admin-console, los logs del JBoss logging y el JBoss Operation Network.
Las 3 herramientas básicas para monitorear JBoss EAP son: jmx-console, admin-console y los logs del jboss ubicados en la carpeta /log
La tecnologia java que permite el monitoreo en tiempo real es el JMX.
Para acceder a la consola JMX en forma remota se debe configurar el archivo /bin/run.conf.bat
El JMX-console provee información sobre la performance y consumo de recursos de una aplicación accediendo a la JVM. El JMX-console cambia atributos en tiempo real.
Para proteger las consolas jmx-console y el admin-console en producción, se debe proteger el archivo de usuarios y passwords.
Para permitir el monitoreo mediante jconsole, se requiere modificar el archivo run.conf.bat que se encuentra en \jboss-as\bin
Se debe agregar debajo de los otros 3 JAVA_OPTS lo siguiente:
set "JAVA_OPTS=%JAVA_OPTS% -Dorg.jboss.platform.mbeanserver"
Se requiere reiniciar el JBoss para que tome estos parámetros.
Para acceder desde línea de comandos a la jmx-console se usa los comandos $jconsole o $jvisualm.
Para acceder remotamente al jconsole agregar las siguientes líneas en el run.conf.bat al final de los otros JAVA_OPTS
rem # Enable the jconsole agent remotely on port 12345
set "JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.jmxremote.port=12345"
set "JAVA_OPTS=%$JAVA_OPTS% -Dcom.sun.management.jmxremote.authenticate=false"
set "JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.jmxremote.ssl=false"
No olvidar comentar la línea
#set "JAVA_OPTS=%JAVA_OPTS% -Dorg.jboss.platform.mbeanserver"
Para que no tenga conflicto con la nueva configuración.
Al iniciar el $jconsole indicar en el parámetro "Remote Process"  la ip y el puerto del JBoss a monitorear como “10.10.10.85:12345”.

Para acceder al admin-console se realiza mediante http://127.0.0.1:8080/admin-console/.
Los parametros del datasource se pueden cambiar en caliente:
                <min-pool-size>1</min-pool-size>
                <max-pool-size>10</max-pool-size>
Una vez cambiadas las variables, estas se visualizan en la consola admin
Max Size             10           Max Size
Min Size              1             Min Size
Para una mejor performance de una configuración en producción, se debe remover el archivo hdscanner-jboss-beans.xml, que está en la carpeta deploy,  para que no se realice la revisión continua de parámetros. También se le puede colocar un  tiempo alto en la variable scanPeriod. Si el scanPeriod=5000 indica que cada 5 segundos revisara los cambios en la carpeta deploy. En producción elevar este valor a 5000000 o borrar el archivo hdscanner-jboss-beans.xml.
hdscanner-jboss-beans.xml
    <!-- Hotdeployment of applications -->
    <bean name="HDScanner" class="org.jboss.system.server.profileservice.hotdeploy.HDScanner">
        <property name="deployer"><inject bean="ProfileServiceDeployer"/></property>
        <property name="profileService"><inject bean="ProfileService"/></property>
        <property name="scanPeriod">5000</property>
        <property name="scanThreadName">HDScanner</property>
    </bean>




Compartir:

JNDI View y el datasource en JBoss EAP 5.0.

Verificación mediante JNDIView de la configuración de un datasource en JBoss EAP 5.0.

Para verificar que el datasource este correcto, se verifica en el jmx-console. Mediante el http://127.0.0.1:8080/jmx-console/ se ubica la opción "service=JNDIView". Luego se utiliza la opción “list-xml” o “list” donde se observara que el datasource está configurado.

jb336DS
org.jboss.resource.adapter.jdbc.WrapperDataSource

Tambien se puede observar el datasource mediante el admin-console, donde se revisa la opción “Datasources”.







Compartir:

Conexión del JBoss EAP 5.0 con una base de datos.

Para que el JBoss se conecte con una Base de Datos se requiere un driver. El driver se obtiene de la pagina web de la base de datos en forma de *.jar. En el caso de MYSQL el driver se encuentra en  mysql-connector-java-5.1.6.jar.
Este conector se debe colocar preferiblemente en la carpeta de las librerías de la aplicación jboss-as/server/desarrollo/lib.  En la ruta \jboss-as\docs\examples\jca  se encuentran varios ejemplos de configuración de conectores a la base de datos. De esta carpeta obtenemos una plantilla llamada mysql-ds.xml (La plantilla mysql-xa-ds se utiliza para transacciones distribuidas o conexiones 2-phase-commit)
La plantilla mysql-ds.xml se copia en la carpeta  \jboss-as\server\jb336\deploy\  para renombrarlo como desarrollo-ds.xml  y configurarlo para nuestro entorno.
En el archivo desarrollo-ds.xml se configura la IP del servidor de datos, el usuario y password de conexión.
    <jndi-name>jb339DS</jndi-name>
    <connection-url>jdbc:mysql://10.10.10.10:3306/jbossdb</connection-url>
    <driver-class>com.mysql.jdbc.Driver</driver-class>
    <user-name>master</user-name>
    <password>password</password>
En el mismo archivo de configuración se agrega una sentencia para que el JBoss verifique que la conexión este vigente, el JBoss realizará el siguiente query:
    <check-valid-connection-sql>select 3</check-valid-connection-sql>
Las políticas de seguridad de la conexión se configuran en el archivo login-config.xml
  <application-policy name="eAplicacion">
    <authentication>
      <login-module code = "org.jboss.security.auth.spi.DatabaseServerLoginModule" flag = "required">
        <module-option name = "dsJndiName">java:/jb336DS</module-option>
                    <module-option name = "principalsQuery">SELECT PASSWORD FROM CUSTOMER WHERE USER_ID=?</module-option>
                    <!-- no roles are needed -->
                    <module-option name = "rolesQuery">SELECT null,null FROM CUSTOMER WHERE USER_ID=?</module-option>
      </login-module>
    </authentication>
  </application-policy>
Compartir:

Como funciona ANT y sus dependencias?

ANT sirve para ejecutar las sentencias de un archivo XML llamado build.xml.
La siguiente sentencia: $ant deploy, buscara el segmento "deploy" del archivo build.xml para ejecutarse. Si este segmento deploy ubicado en el build.xml tiene una directiva "depends", se realizara este segmento previamente.
    <target name="deploy" description="Deploy the packaged archive" depends="archive">
        <fail unless="jboss.home">jboss.home not set</fail>
        <copy todir="${deploy.dir}" file="${calculateService.ear}"/>
        <copy todir="${deploy.dir}" file="${customerManagementService.ear}"/>
        <copy todir="${deploy.dir}" file="${inventoryManagementService.ear}"/>
        <copy todir="${deploy.dir}" file="${orderManagementService.ear}"/>
        <copy todir="${deploy.dir}" file="${common.jar}"/>
        <copy todir="${deploy.dir}" file="${eBikes.ear}"/>
    </target>
Compartir:

lunes, 13 de junio de 2011

Configuracion de las aplicaciones en JBoss EAP 5.0

Las aplicaciones se empaquetan como WAR que tiene la misma estructura de un archivo zip
- en classes estan las clases de la aplicacion
- en lib las librerias jar de la aplicacion
- en web.xml se encuentra el descriptor de la aplicacion. Este es un descriptor estandar.
- en jboss-web.xml se encuentra el descriptor personalizado y es propio de JBoss.

Un paquete de aplicacion o JBoss Service Aplication se encuentran empaquetado en archivos *.sar. Una aplicacion *.sar puede incorporar archivos *.jar, *.war, *.ear. Cuando se define un servicio no se requiere definir una capa de vista servlet o JSP. El descriptor de un SAR es el archivo jboss-service.xml

El cambio de la URL de una aplicacion web no requiere reiniciar el servidor JBoss EAP; se puede cambiar el contexto de la aplicacion. El nombre de la aplicacion esta en el web.xml. Una vez cambiado se puede desplegar nuevamente sin reiniciar el JBoss.

Borrando el paquete del directorio deploy , desinstala la aplicacion. En produccion es preferible no utilizar el deploy automatico en caliente. Para deshabilitarlo se debe remover el archivo hdscanner-jboss-beans.xml que se encuentra en la carpeta deploy (version 5 del JBoss)

El servicio que provee una busqueda de otros servicios en JBoss es el JNDI

Si ocurre algun problema durante el deploy de aplicacion se deben verificar los logs, las consolas, la misma aplicacion o el JNDI view.

La configuracion del despliegue de las aplicaciones se realiza en:
- Los POJOs se despliegan en (nombre-del-POJO)-jboss-bean.xml
- Los servicios MBean en (MBean)-service.xml
- Los datasource se despliegan en (base-de-datos)-ds.xml
Para invocar un datasource de usa JNDI en la forma java:/oracle-ds.xml
En oracle.xml por ejemplo se define la url de conexion, el driver, el usuaio y password, y los parametros del pool de conexiones.

La configuracion “track-statements”, revisa si la conexion esta aun vigente.
La configuracion “security-domain”, permite al datasource estar bajo una politica de seguridad.
La “idle-timeout-minutes” es por defecto 15 minutos, y es el tiempo maximo para devolver la conexion al pool, en caso el servidor de base de datos no responda.
Compartir:

Configuracion de la memoria Java en JBoss EAP.

Cuando la JVM se levanta, se crean los siguientes espacios de memoria:
1. Eden (create de objetos)
2. Survivor (Garbage Colector gc)
3. Old (los eliminados por el gc)
4. Permanent (librerias)
5. Code Cache. Solo presente en la version HostSpot.

El Heap (la union del Eden, Survivor, Old) se determina mediante -Xms y -Xmx, y MaxPermnSize determina el area permanent.

Para modificar el la memoria del JBoss, ubicar en el archivo C:\jboss-eap-5.0\jboss-as\bin\run.conf.bat la siguiente linea:

rem # JVM memory allocation pool parameters - modify as appropriate.
set "JAVA_OPTS=-Xms128M -Xmx512M -XX:MaxPermSize=256M"

Otra configuracion

rem # JVM memory allocation pool parameters - modify as appropriate.
set "JAVA_OPTS=-Xms256M -Xmx1024M -XX:MaxPermSize=256M"

El siguiente parametro indica cada cuanto se desea ejecutar el garbage collector. Realmente lo decide el JVM, y trata de ejecutarlo como lo indica el parametro gcInterval (expresado en milisegundos)

rem # Reduce the RMI GCs to once per hour for Sun JVMs.
set "JAVA_OPTS=%JAVA_OPTS% -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000"
Para revisar monitorear la memoria y otros elementos del Java se puede usar el “jconsole”. Aqui se puede ver como esta configurada la memoria; “jconsole” es parte del JDK.

Otra herramienta es el “jvisualvm” que nos muestra el uso de la memoria del servidor.

Si 1 proceso se ejecuta en 1 segundo y el servidor procesa 5 procesos concurrentes, entonces 10 procesos se ejecutan en 2 segundos. Mientras se procesan los 5 primeros, los restantes estan en espera.

El parametro "Max threads" mostrado por http://10.10.10.83:8080/status indicara la maxima cantidad de procesos concurrentes por segundo.

Para levantar en cluster se puede hacer lo siguiente:

C:\jb336\appservers\jboss-eap-5.0\jboss-as\bin>run.bat -c all -b 0.0.0.0 -Djboss.partition.name=Granja
Compartir:

JBoss EAP: configuracion y comando para el startup (ejemplos)

Una vez obtenido el archivo jboss-eap-5.0.0.GA este se descomprime.
Luego se copia de una configuracion para crear una propia, por ejemplo la nueva configuracion "desarrollo" se copia desde la configuracion "default".
El JBoss EAP tiene las siguientes configuraciones predefinidas:
- default se usa para un proyecto de desarrollo porque tiene el debug configurado.
- produccion es como la configuracion default con mayor afinamiento.
- all es la configuracion utilizada para servidores en cluster
- standard tiene lo necesario para aplicaciones EE. (JNDI, EJBs, JMS, WS, mailing).
- minimal, levanta lo minimo para operar el microcontenedor
- web, solo instala soporte a servlets y JSP , es equivalente a Tomcat.

Una configuracion, al momento de iniciar, crea las siguientes carpetas:
- log: archivos log
- tmp: archivos temporales del JBoss EAP.
- work: archivos temporales del servidor web y JSP
- data: base de datos hypersonic en memoria del servidor, aqui se mantienen las colas.
Luego de iniciar el servicio aparecen las nuevas carpetas. Se pueden borrar estas carpetas al momento de reiniciar el servidor.

Ejemplo de inicio de un JBoss
$run.sh -c desarrollo -b 10.10.10.10

Al momento de subir el servidor, hay que verificar que no se muestren errores al levantar el servicio. Un error comun es utilizar los puertos que otro servicio ya ha ocupado.

El log muestra cuanta memoria se ha utilizado:

17:38:42,234 INFO [ServerInfo] VM arguments: -Dprogram.name=run.bat -Xms128M -Xmx512M -XX:MaxPermSize=256M -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Dorg.jboss.

Segun este log se usara entre 128 y 512Mb

La aplicacion tomcat status muestra las estadisticas del servidor. El JBoss no cuenta con instalador, solo se descomprime. Si presenta problemas , se deben revisar que el archivo descargado este completo, que la version de java sea compatible con el JBoss; que la variable JAVA_HOME este declarada y los conflictos de puertos o conflictos con otros procesos.

Cuando se cuentan con varias versiones de JBoss instalados, se requiere configurar la variable JBOSS_HOME.
Compartir:

Estructura de directorios del JBoss EAP

En la carpeta jboss-as se encuentra el servidor.
En bin se encuentra los ejecutables
En common se encuentran las librerias comunes al container (comunes a todas configuraciones)
En server se encuentran las configuraciones
En lib se encuentran las librerias jar del microcontainer
En seam se encuentra el framework SEAM

En jboss/lib se encuentran las librerias para que el microcontenedor funcione.
En jboss/common/lib se encuentran las librerias comunes a todas las configuraciones
Compartir:

Configuración y opciones del startup del JBoss

Durante el startup del JBoss se cargan los servicios del core que se encuentra definidos en el archivo conf/bootstrap.xml. Tambien se cargan los servicos de la aplicacion configurados en la carpeta conf/ y en el archivo bootstrap/profile.xml. Aqui se indican cuales son los beans utilizados especialmente para aplicaciones legacy.

El directorio server/configuracion/conf es escaneado cada 60 segundos para revisar cambios en la configuracion del log4j.xml (niveles del log). Cualquier otro cambio fuera del log4j se requiere bajar y subir el server.

Se debe configurar la variable de entorno JAVA_HOME para correr el JBoss.

Opciones del startup de JBoss.
Para levantar el JBoss se realiza con el comando run.sh en Linux o run.bat en Windows.
Ejemplos:
- Para levantar la configuracion “produccion” con determinada IP (si el servidor tuviera varias tarjetas de red)
$ run.sh -c produccion -b 192.168.1.30
- Si se desea que el servicio se despliegue en todas las IPs presentes en el servidor.
$ run.sh -c produccion -b 0.0.0.0
- Si no se coloca -b el servicio corre en la direccion local 127.0.0.1
- Si solo se tiene una tarjeta se requerira usar IPs virtuales para desplegar varios servidores. Se recomienda tener varias tarjetas.
- Si no se le pone -c, el JBoss utiliza la configuracion “deafult” en la version comunity y la configuracion “production” en la version JBoss EAP.
- Si se desea que corra en background, se utiliza el “daemon” que se encuentra en la carpeta “bean” (para los diversos sistemas operativos) que viene con el JBoss.
- Para levantar en cluster, se le indica el cluster con -D. El JBoss busca en la red otros JBoss con el mismo nombre “Granja”. Si no existiese alguno, se convierte como servidor primario .
$ run.sh -c mycluster -b 10.0.0.2 -Djboss.partition.name=Granja
Compartir:

El microcontenedor JBoss. Caracteristicas.

El JBoss es un grupo de componentes que trabajan de manera coordinada y el JBoss microcontainer es el responsable que estos modulos de servicios trabajen de manera coordinada. Los modulos se pueden retirar del JBoss si no se requieren.

Los componentes del JBoss son:
- Los servicios empresariales: Mensajeria entre objetos, Clustering, Seguridad, Transacciones, Servidor Web, WebSevrice, Mapeos Objeto-Relacional.
- Los componentes de despliegue: POJO, MBean, JavaEE, SPring, OSCGI.
- Las aplicaciones de usuario: service.xml (configuracion de servcios), OSGI , jboss-beans (portlets), spring beans, *.ear (aplicaciones empresariales), *.war(aplicaciones web)

Los modulos del microcontainer son: Reflect, MDR, Managed, Kernel, VFS, CL, Deployers, Reliance, OSGI, Integr, Tools.

El papel del microcontainer en JBoss es coordinar los modulos del JBoss y servir de integrador entre los diversos modulos del JBoss.
Compartir:

JBoss Developer Studio. Caracteristicas

El JBoss developer studio permite desarrollar componentes JBoss y desplegarlos en JBoss, SOA, Portal o JBoss Enterprise Application Server. JBoss Developer Studio esta basado en Eclipse.

Java es el lenguaje (como VisualBasic) y Java EE (aplicacion empresarial) es la plataforma (como .Net). Java EE, usa servicio de nombres JNDI, EJBs, mensajeria JMS, soporte a webservices, mailing.
Compartir:

JBoss SOA Plataform. Caracteristicas

Esta plataforma permite identificar servicios, especificar servicios y construir servicios. JBoss SOA Plataform integra las siete capas del modelo a saber:

7. Gestion de Seguridad
6. Integracion
5. Presentacion
4. Orquestacion de Servicios
3. Organizacion de Servicios
2. Componentes empresariales
1. Sistemas Operacionales
Compartir:

JBoss Enterprise Application Plataform (JBoss EAP)

El JBoss EAP se usa en aplicaciones web de mision critica mediante clusters. Esta basado en Tomcat, por lo que es sencilla la migracion a partir de Tomcat. Soporta frameworks estandares Spring, JSP, Hibernate, etc. Soporta frameworks complejos como SEAM, EJBs, JMS, caching. Tambien maneja herramientas para integrar otros servicios como JMS, Corba, JMX.

El JBoss soporta aplicaciones nativas en Java, siendo el JVM es independiente del sistema operativo. Con herramientas de terceros puede soportar componentes de otras plataformas. Presenta alta escalabilidad.

El JBoss EAP es Open Source, 100% java puro y no incorpora elementos propietarios. Es un servidor de aplicaciones basado en estándares

Para elegir una plataforma JBoss EAP debe considerar:
- Elegir el sistema operativo.
- Elegir si es en 32 bits o 64 bits.
- Elegir cuanta memoria utilizará. Java solo puede utilizar 2 GB de RAM en 32 Bits. A 64 bits no hay maximo.
- Elegir su configuración de red.

Como requisito primero se debe instalar el JDK. Para el JBoss se debe instalar la version de Java correcta. La version de JBoss 5.0 usará el JDK 1.5. La version JBoss 6.0 usaré el JDK 1.6. Hay un JDK diferente para cada sistema operativo.

Oracle cuenta con dos versiones de Java. La version HOTSPOT es el Java de SUN. La version ROCKY es el Java de BEA.
Compartir:

Servicios JBoss: Operation Network, Drools, jBPM, Portal, ESB.

JBoss empezó como servidor de aplicaciones, pero ahora cuenta con nuevos servicios como:

1. JBoss Operation Network, que es una herramientas para administrar servidores, clusters, granjas y alta disponibilidad. Mantiene metricas de red, memoria, cpu, disco, aplicaciones, informando mediante alertas preventivas. Para ello se instala agentes en servidores JBoss, Apache, Mysql con el fin de recolertar estas metricas.

2. Drools (Reglas de negocio) y jBPM (Procesos de negocio). Es un framework para analisis de negocios y procesos. Las reglas de negocio ya no se encuentran en los EJB, dependientes del programador, sino en un repositorio llamado Drools para que los analistas funcionales puedan modificar directamente las reglas que se implementan mediante una hoja excel o seudocodigo. El jBPM es un motor workflow.

3. JBoss Portal, es un administrador de portales y esta potenciado con la adquision de Gatein (EXO Plataform). Sirve para integrar aplicaciones.

4. JBoss ESB, es un herramienta util para la integracion de arquitecturas; los servicios se de todas las plataformas se publican en el ESB para que sean accedidos desde cualquier arquitectura.
Compartir:

Historia del JBoss

Esta hecho por desarrolladores para desarrolladores y se focaliza en la simplicidad. JBoss fue el primer EJB container open source. En el 2006 Redhat compra JBoss y actualmente compite con Weblogic de Oracle y Websphere de IBM. La compañia Oracle cuenta con tres servidores de aplicaciones: Glassfish (comprada a SUN), Weblogic (comprada a BEA) y OAS (desarrollado por Oracle). Por tema de costos los proyectos recientes son migraciones desde Websphere hacia JBoss y desde Weblogic a JBoss, principalmente por el costo de licencias.
Compartir: