CursoJbossJboss

JBoss #

Introducción #

Es una implementación open-source del lo que se conoce como contenedor de EJBs. Dentro de las capas de Java EE, antes J2EE, había una capa web un capa de lógica de negocio, y una capa de datos. En cada capa se definen las características que debe cumplir los contenedores de los módulos (componentes) y las caracterísitcas de los contenedores. Se define por ejemplo las características que debe tener un servlete (orientadas al desarrollador) pero también las características del contenedor que debe controlar dicho componente (contenedor de servlets). Dentro de todo este esquema Jboss es un implementación del contenedor de EJBs. Jboss se suele distribuir conjuntamente con un contenedor de servlets (antes jetty ahora tomcat) para poder identificarlo como un "Fully J2EE Complian". Ya que el resto de los servidores de aplicaciones del mercado (propietarios en su mayoría) son productos en los que se implementan ambas características de manera holísitca.

WebLogic (bea)
Websphere (ibm)
Oracle 9i Application Server (oracle)

La versión estable de Jboss actual (noviembre de 2006) implementa el estandar J2EE 1.4 no Java EE 1.5. Eso si implementa las especificaciones para poder desplegar en él EJBs 3.0 De la página de Jboss (ahora comprado por redHat) A J2EE certified platform for developing and deploying enterprise Java applications, Web applications, and Portals, JBoss Application Server provides the full range of J2EE 1.4 features as well as extended enterprise services including clustering, caching, and persistence. Existe una beta que implementa el estandar Java EE 1.5 De la página de Jboss JBoss AS 5 GA will be EE 5 certified and will include the following core technologies

JBoss Microcontainer - POJO based microcontainer removing the dependency on JMX
Hibernate 3.2 - JPA certified
JBoss Messaging 1.2 - the next generation messaging platform from JBoss with HA features.
JBoss WebServices 2.0 - new custom built JAX-WS compliant WebServices stack.
JBoss Seam 1.1 - a powerful new application framework to build next generation Web 2.0 applications by unifying and integrating popular service oriented architecture (SOA) technologies

Arquitectura de JBoss #

Arquitectura en 4 capas de Jboss

Microkernel Layer

Capa principal sobre la que se construye el servidor de aplicaciones, haciendo uso del la implementación de JMX se encarga de gestionar los componentes, despliegue en caliente, class-loader y ciclo de vida de los mismos. Para dicha gestión se podrá utilizar la consola web JMX.

Services Layer

Por encima de la capa de micro-kernel se encuentra la capa de servicios. Son una serie de servicios que se pueden desplegar, y cubren funcionalidades como:

Servicio de transacciones (JBossTX)
Servicio de mensajeria (JbossMQ)
Servicio de mails JavaMail
Servicio de seguridad (JbossSX)
Servicio de pool de base de datos (JNDI/JDBC)

Se pueden añadir nuevos servicios a esta capa y manejar los existentes, hot-deploy, hot-undeploy de los mismos para poder configurar el servidor de aplicaciones acorde con las necesidades de cada momento

Aspect Layer AOP

Capa del servidor orientada a la AOP, para poner a disposición del resto de objetos las "Incumbencias transversales", que es un termino que se utiliza en AOP para definir las relaciones(metodos) que no estan dentro de un esquema jerarquico de una programación OO.

Application Layer

Capa donde resisden las aplicaciones en esta capa puede hacer uso de la infraestructura de JBOSS.

Instalación de JBoss #

Pasamos a continuación a describir brevemente el proceso de instalación de JBOSS 4.0.5.

Software necesario y requisitos #

JDK 1.4 o 1.5
JAVA_HOME apuntando al sitio correcto
Una versión binaria del JBOSS 4.0.5 o el instalador

Proceso de Instalación #

Ejecutar el instalador [code|codejava|-jar jems-installer-1.2.0.CR1.jar/code]

En esta pantalla pide información para saber como se quiere hacer la carga de clases. WARs con misma paquetería pueden generar problemas a en los despliegues. ClassLoadingConfiguration Configuracion del classLoader] http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossClassLoadingUseCases Articulo sobre la carga de clases]

La estructura que se ha instalado es la siguiente: codegus@metropolis:~/jboss-4.0.5.GA$ tree -L 1 ./ ./

-- InstallSummary html
-- Uninstaller
-- bin
-- client
-- docs
-- lib
-- scripts

`-- server /code

Arranque y parada del servidor #

[code].SLArun.sh/code./run.sh/code] Arranca el servicio en consola [code|code./shutdown.sh|-S -u admin -p admin/code] Detiene el servidor arrancado, para detenerlo hay que validar el usuario

Instalar jboss como servicio #

La instalación como servicio depende principalmente del sistema operativo, en el caso que nos ocupa habrá que generar el script necesario y hacer que se arranque/pare el jboss en los niveles deseados. A modo de ejemplo en la carpeta bin existen varios scripts de ejemplo para distintas distros codegus@metropolis:~/jboss-4.0.5.GA$ tree ./bin/ ./bin/

-- classpath.sh
-- jboss_init_hpux.sh
-- jboss_init_redhat.sh
-- jboss_init_suse.sh
-- probe.bat
-- probe.sh
-- run.bat
-- run.conf
-- run.jar
-- run.sh
-- shutdown.bat
-- shutdown.jar
-- shutdown.sh
-- twiddle.bat
-- twiddle.jar
-- twiddle.sh
-- wstools.bat

`-- wstools.sh /code Para redhat por ejemplo habría que editar el archivo jboss_init_redhat.sh y configurar los parámetros (JBOSS_HOME, USER etc..), copiarlo a /etc/init.d/ y añadirlo a los niveles de arranque codechmod +x /etc/init.d/tomcat chkconfig jboss_init_redhat.sh --add chkconfig jboss_init_redhat.sh on /code Para ubuntu dapper habría que hacer algo similar pero habría que modificar el script para que las herramientas de automatizacion sean capaces de saber en que niveles se debe arrancar el jboss code# Startscript for Jboss

chkconfig: - 87 15
description: Jboss Startcript
processname: jboss

/code y ejecutar luego el comando [code]update-rc.d/codeupdate-rc.d/code]

JMX #

Para acceder a la consola de JMX que es la base del JBOSS, apuntar el navegador a la url de acceso a la consola JMX

Microkernel de Jboss #

Servicios #

Configuración e implementaciones de los distintos API #

JNDI/JDBC #

Vamos a crear un nueva base de datos con su usuario y vamos a publicar el pool de conexiones a la misma en el arbol JNDI del jboss S.O: ubuntu server (6.06) dapper-drake Motor de la base de datos: Postgresql 8.1 Nombre de la base de datos: app-db Usuario de la base de datos: appUser Primero mediante aptitude instalamos el motor de base de datos. [code|codeaptitude|install postgresql-8.1/code] Creamos el usuario appUser codepostgres@metropolis:~$ createuser -P appUser Ingrese la contraseña para el nuevo rol: Ingrésela nuevamente: ¿Será el nuevo rol un superusuario? (s/n) n ¿Debe permitírsele al rol la creación de bases de datos? (s/n) s ¿Debe permitírsele al rol la creación de otros roles? (s/n) s CREATE ROLE /code Creamos la base de datos app-db para este usuario codepostgres@metropolis:~$ createdb -O appUser app-db CREATE DATABASE /code Descargamos el friver que vamos a utilizar en la conexión (driver jdbc) [code|codegus@metropolis:/tmp$|wget http://jdbc.postgresql.org/download/postgresql-8.1-407.jdbc3.jar[/code|SLAcode]] Copiamos el jar code$JBOSS_HOME/server/default/lib}

gus@metropolis:~$ cp Desktop/curso-jboss/practica-JNDI-JDBC/postgresql-8.1-407.jdbc3.jar /home/gus/jboss-4.0.5.GA/server/default/lib
[[/code|/code]]
Copiamos el datasource descriptor
[[[code|[code]]cp|Desktop/curso-jboss/practica-JNDI-JDBC/app-ds.xml /home/gus/jboss-4.0.5.GA/server/default/deploy/[[/code|/code]]]
El contenido del archivo es
[[code|code]]<?xml version="1.0" encoding="UTF-8"?>
<datasources>
{{{
   <local-tx-datasource>
      <!-- The jndi name of the [[DataSource|DataSource]]  it is prefixed with java:/ -->
      <!-- Datasources are not available outside the virtual machine -->
      <jndi-name>appDS</jndi-name>
      <connection-url>jdbc:postgresql://localhost:5432/app-db</connection-url>
      <!-- The driver class -->
      <driver-class>org.postgresql.Driver</driver-class>
}}}

{{{
      <!-- The login and password -->
      <user-name>appUser</user-name>
      <password>appUser</password>
}}}

{{{
      <!-- this will be run before a managed connection is removed from the pool for use by a client-->
      <check-valid-connection-sql>select 1</check-valid-connection-sql>
}}}

{{{
      <!-- The minimum connections in a pool/sub-pool. Pools are lazily constructed on first use -->
      <min-pool-size>1</min-pool-size>
}}}

{{{
      <!-- The maximum connections in a pool/sub-pool -->
      <max-pool-size>2</max-pool-size>
}}}

{{{
      <!-- The time before an unused connection is destroyed -->
      <idle-timeout-minutes>5</idle-timeout-minutes>
      <!-- Whether to check all statements are closed when the connection is returned to the pool,
           this is a debugging feature that should be turned off in production -->
      <track-statements/>
      <!-- HSQL DB 1.7.2 benefits from prepared statement caching -->
      <prepared-statement-cache-size>32</prepared-statement-cache-size>
   </local-tx-datasource>
}}}
</datasources>
[/code|/code]
En este momento el JBoss publica la conexión en el JNDI y ya se podría utilizar
[[code|[code]13:17:37,380|INFO  [ [WrapperDataSourceService|WrapperDataSourceService] ] Bound [ConnectionManager|ConnectionManager] 'jboss.jca:service [DataSourceBinding|DataSourceBinding] name=appDS' to JNDI name 'java:appDS'[/code|/code]]
Una vez realizado lo anterior podemos ir a la consola JXM y ver que realmente el recurso está publicado.

<img src="/image/image_gallery?img_id=12563&t=1206444602888" />

Podemos ver el arbol JNDI invocando el servicio JNDIView y su metodo list()
[code|code]+- jaas (class: javax.naming.Context)
{{{
  |   +- [[HsqlDbRealm|HsqlDbRealm]] (class: org.jboss.security.plugins [[SecurityDomainContext|SecurityDomainContext]] 
  |   +- jmx-console (class: org.jboss.security.plugins [[SecurityDomainContext|SecurityDomainContext]] 
  |   +- jbossmq (class: org.jboss.security.plugins [[SecurityDomainContext|SecurityDomainContext]] 
  |   +- JmsXARealm (class: org.jboss.security.plugins [[SecurityDomainContext|SecurityDomainContext]] 
  +- [[TransactionPropagationContextImporter|TransactionPropagationContextImporter]] (class: org.jboss.tm [[TransactionPropagationContextImporter|TransactionPropagationContextImporter]] 
  +- JmsXA (class: org.jboss.resource.adapter.jms [[JmsConnectionFactoryImpl|JmsConnectionFactoryImpl]] 
  +- JBossCorbaNaming (class: org.omg [[CosNaming|CosNaming]] NamingContextExt)
  +- DefaultDS (class: javax.sql [[DataSource|DataSource]] 
  +- StdJMSPool (class: org.jboss.jms.asf [[StdServerSessionPoolFactory|StdServerSessionPoolFactory]] 
  +- [[TransactionManager|TransactionManager]] (class: org.jboss.tm [[TxManager|TxManager]] 
  +- JBossCorbaPOA (class: org.omg [[PortableServer|PortableServer]] POA)
  +- [[TransactionPropagationContextExporter|TransactionPropagationContextExporter]] (class: org.jboss.tm [[TransactionPropagationContextFactory|TransactionPropagationContextFactory]] 
  +- [[ConnectionFactory|ConnectionFactory]] (class: org.jboss.mq [[SpyConnectionFactory|SpyConnectionFactory]] 
  +- DefaultJMSProvider (class: org.jboss.jms.jndi.JNDIProviderAdapter)
  +- XAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)
  +- JBossCorbaInterfaceRepositoryPOA (class: org.omg [[PortableServer|PortableServer]] POA)
  +- Mail (class: javax.mail.Session)
  +- JBossCorbaORB (class: org.omg.CORBA.ORB)
  +- timedCacheFactory (class: javax.naming.Context)
}}}
Failed to lookup: timedCacheFactory, errmsg=org.jboss.util [TimedCachePolicy|TimedCachePolicy] {{{
  +- [[SecurityProxyFactory|SecurityProxyFactory]] (class: org.jboss.security [[SubjectSecurityProxyFactory|SubjectSecurityProxyFactory]] 
  +- comp (class: javax.naming.Context)
  +- appDS (class: javax.sql [[DataSource|DataSource]] 
}}}
[/code|/code]
Si cambiamos el nombre del JNDI desde su bean correspondiente name=appDS,service [DataSourceBinding|DataSourceBinding] a appDS2 Podemos ver que el arbol JNDI cambia
[code|code]+- jaas (class: javax.naming.Context)
{{{
  |   +- [[HsqlDbRealm|HsqlDbRealm]] (class: org.jboss.security.plugins [[SecurityDomainContext|SecurityDomainContext]] 
  |   +- jmx-console (class: org.jboss.security.plugins [[SecurityDomainContext|SecurityDomainContext]] 
  |   +- jbossmq (class: org.jboss.security.plugins [[SecurityDomainContext|SecurityDomainContext]] 
  |   +- JmsXARealm (class: org.jboss.security.plugins [[SecurityDomainContext|SecurityDomainContext]] 
  +- [[TransactionPropagationContextImporter|TransactionPropagationContextImporter]] (class: org.jboss.tm [[TransactionPropagationContextImporter|TransactionPropagationContextImporter]] 
  +- JmsXA (class: org.jboss.resource.adapter.jms [[JmsConnectionFactoryImpl|JmsConnectionFactoryImpl]] 
  +- JBossCorbaNaming (class: org.omg [[CosNaming|CosNaming]] NamingContextExt)
  +- DefaultDS (class: javax.sql [[DataSource|DataSource]] 
  +- StdJMSPool (class: org.jboss.jms.asf [[StdServerSessionPoolFactory|StdServerSessionPoolFactory]] 
  +- [[TransactionManager|TransactionManager]] (class: org.jboss.tm [[TxManager|TxManager]] 
  +- JBossCorbaPOA (class: org.omg [[PortableServer|PortableServer]] POA)
  +- [[TransactionPropagationContextExporter|TransactionPropagationContextExporter]] (class: org.jboss.tm [[TransactionPropagationContextFactory|TransactionPropagationContextFactory]] 
  +- [[ConnectionFactory|ConnectionFactory]] (class: org.jboss.mq [[SpyConnectionFactory|SpyConnectionFactory]] 
  +- appDS2 (class: javax.sql [[DataSource|DataSource]] 
  +- DefaultJMSProvider (class: org.jboss.jms.jndi.JNDIProviderAdapter)
  +- XAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)
  +- JBossCorbaInterfaceRepositoryPOA (class: org.omg [[PortableServer|PortableServer]] POA)
  +- Mail (class: javax.mail.Session)
  +- JBossCorbaORB (class: org.omg.CORBA.ORB)
  +- timedCacheFactory (class: javax.naming.Context)
}}}
Failed to lookup: timedCacheFactory, errmsg=org.jboss.util [TimedCachePolicy|TimedCachePolicy] {{{
  +- [[SecurityProxyFactory|SecurityProxyFactory]] (class: org.jboss.security [[SubjectSecurityProxyFactory|SubjectSecurityProxyFactory]] 
  +- comp (class: javax.naming.Context)
}}}
[/code|/code]
En el log del jboss se ve la operación
[[code|[code]14:20:27,145|INFO  [ [WrapperDataSourceService|WrapperDataSourceService] ] Bound [ConnectionManager|ConnectionManager] 'jboss.jca:service [DataSourceBinding|DataSourceBinding] name=appDS' to JNDI name 'java:appDS2'[/code|/code]]
Si reiniciamos el Jboss los cambios no tiene efecto ya que vuelve a leer los datos del xml original
Creamos ahora una tabla de usuarios en la base de datos y un usuario. Posteriormente se hará uso de esta tabla para cambiar el modelo de autenticación de la consola-jmx
[code|code]postgres@metropolis:~$ psql -U appUser
psql: FATAL:  no existe la base de datos «appUser»
postgres@metropolis:~$ psql -U appUser app-db
Bienvenido a psql 8.1.4, la terminal interactiva de PostgreSQL.

Digite:  \copyright para ver los términos de distribución
{{{
       \h para ayuda de comandos SQL
       \? para ayuda de comandos psql
       \g o or termine con punto y coma para ejecutar una consulta
       \q para salir
}}}

app-db=>

Ejecutamos las siguientes sentencias

app-db=> CREATE TABLE Users(username VARCHAR(64) PRIMARY KEY, passwd VARCHAR(64))
app-db-> ;
NOTICE:  CREATE TABLE / PRIMARY KEY creará el índice implícito «users_pkey» para la tabla «users»
CREATE TABLE
app-db=> select * from Users;
{{{
 username | passwd
}}}
----------+--------
(0 filas)

app-db=> CREATE TABLE [UserRoles|UserRoles] username VARCHAR(64), userRoles VARCHAR(32));
CREATE TABLE
app-db=> INSERT INTO Users VALUES ('200','j2ee') ;
INSERT 0 1
app-db=> INSERT INTO [UserRoles|UserRoles] VALUES ('200','bankCustomer');
INSERT 0 1
app-db=> select * from Users [UserRoles|UserRoles] 
{{{
 username | passwd | username |  userroles
}}}
----------+--------+----------+--------------
{{{
 200      | j2ee   | 200      | bankCustomer
}}}
(1 fila)
[/code|/code]
Si queremos crear otro dataSource para otra base de datos, basta con seguir los pasos indicados para el ejemplo de postgres, pero modificandp el driver jdbc y el archvio app-dx.xml. Una lista de plantillas de archivos *-ds.xml se encuentra en la carperta doc/examples/jca
[code|code]gus@metropolis:~/jboss-4.0.5.GA/docs/examples/jca$ tree
.
|-- asapxcess-jb3.2-ds.xml
|-- cicsr9s-ds.xml
|-- db2-400-ds.xml
|-- db2-ds.xml
|-- db2-xa-ds.xml
|-- derby-ds.xml
|-- facets-ds.xml
|-- fastobjects-jboss32-ds.xml
|-- firebird-ds.xml
|-- generic-ds.xml
|-- hajndi-jms-ds.xml
|-- hsqldb-ds.xml
|-- hsqldb-encrypted-ds.xml
|-- informix-ds.xml
|-- informix-xa-ds.xml
|-- jboss-ha-local-jdbc.rar
|-- jboss-ha-xa-jdbc.rar
|-- jdatastore-ds.xml
|-- jms-ds.xml
|-- jsql-ds.xml
|-- lido-versant-service.xml
|-- mimer-ds.xml
|-- mimer-xa-ds.xml
|-- msaccess-ds.xml
|-- mssql-ds.xml
|-- mssql-xa-ds.xml
|-- mysql-ds.xml
|-- oracle-ds.xml
|-- oracle-xa-ds.xml
|-- pointbase-ds.xml
|-- pointbase-xa-ds.xml
|-- postgres-ds.xml
|-- progress-ds.xml
|-- sapdb-ds.xml
|-- sapr3-ds.xml
|-- solid-ds.xml
`-- sybase-ds.xml
[/code|/code]
!! JBOSS [ClassLoader|ClassLoader] 
La carga de clases en jboss se hace de manera que minimice el numero de clases cargadas, por lo que esto puede generar problemas porque impide que existan clases que se llamen igual, y hagan cosas diferentes. Obligando a que los war unicamente contengan los contenidos web y los servlets, los EJBs las implementaciones de sus interfaces etc.. Esto puede generar problemas como ya hemos en dos casos:
* Diseños que no se ajusten a lo anterior
* Neceisda de usar distintas versiones de una libreria en apliacaciones
Para subsanar lo anterior hay que realizar despliegues asilados unos de otros dentro del contenedor.En el despliegue se pueden pretender dos cosas:
* Aislar el despliegue de otras aplicaciones
* Aislar el despliegue de las clases cargadas (permitir la sobrecarga de algunas clases versiones diferentes de las librerias)
El primer caso se resuelve en un .ear(jboss-app.xml), .war(jboss-web.xml), .sar(jboss-service.xml) de añadiendo los siguiente al deploy descriptor
[code|code]<jboss-app>
{{{
   <loader-repository> 
   com.example:loader=unique-archive-name 
   </loader-repository> 
}}}
</jboss-app>
[[/code]

[code]]<jboss-web>
{{{
   <class-loading> 
      <loader-repository> 
      com.example:loader=unique-archive-name 
      </loader-repository> 
   </class-loading>
}}}
</jboss-web> 
[[/code]

[code]]<server>
{{{
        <loader-repository>
                com.example:loader=unique-archive-name 
        </loader-repository>
}}}
</server>
[/code|/code]
unique-archive-name puede ser por ejemplo nombre_aplicacion.(ear|war|sar)
El segundo caso se resuleve con la siguiente configuración
[code|code]<jboss-app>
{{{
  <loader-repository> 
  com.example:loader=unique-archive-name 
     <loader-repository-config> 
     java2ParentDelegation=false 
     </loader-repository-config> 
  </loader-repository>
}}}
</jboss-app>
[[/code]
[code]]<jboss-web>
{{{
 <class-loading java2ClassLoadingCompliance="false">
 <loader-repository>
 com.example:loader=unique-archive-name
 <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
 </loader-repository>
 </class-loading>
}}}
...
{{{
 <server>
      <loader-repository> com.example:loader=unique-archive-name <loader-repository-config>java2ParentDelegation=false</loader-repository-config>         
      </loader-repository> 
}}}
...

/code Un aplicacion cargada de esta manera sigue el siguiente patron de carga de clases: 1. APP-INF/lib (for EARs) and WEB-INF/lib (for WARs) 1. libraries in server/default/lib 1. tomcat-libraries in server/default/deploy/jbossweb-tomcat50.sar (jboss-3.2.6) Para el servicio jbossweb-tomcat41.sar/META-INF/jboss-service.xml revisar además el parametro UseJBossWebLoader Se puede hacer que todo el servidor se comporte de manera aislada para ello, la configuracion tiene que ser, code

 <mbean code="org.jboss.deployment.EARDeployer" name="jboss.j2ee:service=EARDeployer">
 <!-- Isolate all ears in their own classloader space -->
 <attribute name="Isolated">true</attribute>
 <!-- Enforce call by value to all remote interfaces -->
 <attribute name= [[CallByValue|CallByValue]] >true</attribute>
 </mbean>

/code en el archivo conf/jboss-service.xml para la versión 3.x o en el archivo deploy/ear-deployer.xml en la version 4.x Hacer esto general el problema de como acceder de manera transeversal a los distintos recursos desplegados. Además hay que tener en cuenta que al hacer lo anterior se realizan las llamadas por valor y no por referencia lo cual es mucho mas ineficiente Call By Reference 1. caller does ejb.someMethod() 1. invocation is passed through ejb container 1. container does bean.someMethod() 1. result is returned to the caller Call By Value 1. caller does ejb.someMethod() 1. invocation is marshalled - the parameters are turned into ObjectStream (a byte[|) 1.|container with a different classloader unmarshalls - byte[]|]]] -> java Objects - including classloading 1. invocation is passed through ejb container 1. container does bean.someMethod() 1. result is marshalled - the return value is turned into ObjectStream 1. result is unmarshalled using the caller's classloader - byte -> java Object 1. result is return to the caller

JBossMQ #

La implementación que se ha hecho de JMS es JBossMQ, construida en varias capas

Capa de FrontEnd * Capa de invocacion
Capa de interceptores (AOP)
Capa de destino

Ejemplo de envio QueueSender -> ServerIL? -> network -> ServerILService? -> JMSServerInvoker -> TracingInterceptor -> SecurityInterceptor -> JMSDestinationManager? -> JMSQueue? -> PersistentQueue Ejemplo de recepción QueueReceiver -> ServerIL? -> network -> ServerILService? -> JMSServerInvoker -> TracingInterceptor -> SecurityInterceptor -> JMSDestinationManager? -> ClientConsumer -> JMSQueue? -> PersistentQueue === JBossCMP ===

JBossTX #

Análisis de logs de JBoss #

Seguridad #

En las aplicaciones en general una de las partes importantes es el modelo de seguridad. Existe un estandar JAAS para que el desarrollador no se tenga que preocupar del diseño de esta parte. J2EE define como debes realizarse las restricciones de seguridad dentro de las aplicaciones, pero no dice como se debe se debe implemntar este modelo dentro del contenedor o como debe configurar. JBoss hace uso de JAAS para implementar el modelo de seguridad. y el modelo de seguridad se basa en la configuración y el acceso restringido a los recursos por medio de roles. 1. Se define un usuario y unos roles 1. Se dice a que recursos tine acceso un rol 1. Se define un dominio a securizar 1. Se define un acceso a los datos de usuarios/roles (file, dabatbase, ldap son implementaciones que ya trae jboss, aunque podrías codificar tu porpio provider de seguridad) Lo anterior se hace declarativamente en el deploy descriptor del componente (ejb, aplicacion web etc..)

JBossSX #

Vamos a modificar el modelo de seguridad de la JMX-console para ver como funciona en realidad 1. Primero quitamos la seguridad 1. Cambiamos el provider para que haga uso de la base de datos postgres y el data-source appDS Primero veamos la estructura del WEB-INF del war desplegado del aplicativo jmx-console codegus@metropolis:~/jboss-4.0.5.GA/server/default/deploy/jmx-console.war$ tree .

-- META-INF
`-- MANIFEST.MF
-- WEB-INF
	-- classes
	`-- org
	`-- jboss
	`-- jmx
	`-- adaptor
		-- control
			-- AddressPort class
			-- AttrResultInfo class
			-- OpResultInfo class
		`-- Server.class
		-- html
			-- ClusteredConsoleServlet class
			-- HtmlAdaptorServlet class
		`-- JMXOpsAccessControlFilter.class
	`-- model
		-- DomainData class
	`-- MBeanData.class
	-- jboss-web.xml
`-- web.xml
-- checkJNDI.jsp
-- cluster
	-- bootstrap.html
	-- clusterView.jsp
`-- index.html
-- displayMBeans.jsp
-- displayOpResult.jsp
-- images
`-- logo.gif
-- index.jsp
-- inspectMBean.jsp
-- jboss.css

`-- style_master.css /code Los archivos que hay que editar son jboss-web.xml y web.xml Para desactivar la seguridad basta con comentar lo siguiente en el archivo jboss-web.xml [code]<security-domain>java:SLAjaasSLAjmx-console<SLAsecurity-domain>/code<security-domain>java:/jaas/jmx-console</security-domain>/code] y lo siguiente en el archivo web.xml code <security-constraint>

     <web-resource-collection>
       <web-resource-name [[HtmlAdaptor|HtmlAdaptor]] /web-resource-name>
       <description>An example security config that only allows users with the
         role JBossAdmin to access the HTML JMX console web application
       </description>
       <url-pattern>/*</url-pattern>
       <http-method>GET</http-method>
       <http-method>POST</http-method>
     </web-resource-collection>
     <auth-constraint>
       <role-name>JBossAdmin</role-name>
     </auth-constraint>
   </security-constraint>
   <security-constraint>
    <web-resource-collection>
       <web-resource-name>Public</web-resource-name>
       <url-pattern>/public/*</url-pattern>
       <http-method>GET</http-method>
       <http-method>POST</http-method>
     </web-resource-collection>
   </security-constraint>
   <login-config>
      <auth-method>BASIC</auth-method>
      <realm-name>JMXConsole</realm-name>
   </login-config>

   <security-role>
      <role-name>JBossAdmin</role-name>
   </security-role>

/code Con lo anterior tenemos ya la aplicación sin securizar. Volvemos a securizar y ahora vamos a cambiar el provider para que haga uso de los datos almacenados en la base de datos. Primero editamos el archivo config-login.xml [code|codegus@metropolis:~/jboss-4.0.5.GA/server/default/conf$|vi login-config.xml/code] Sin modificar el archivo la configuración el provider es code<application-policy name = "jmx-console">

   <authentication>
      <login-module code="org.jboss.security.auth.spi [[UsersRolesLoginModule|UsersRolesLoginModule]]  flag = "required">
       <module-option name="usersProperties">props/jmx-console-users.properties</module-option>
       <module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
      </login-module>
   </authentication>

</application-policy> /code Lo modificamos para que haga uso de los datos de la base de datos code <application-policy name="jmx-console">

   <authentication>
    <login-module code="org.jboss.security.auth.spi [[DatabaseServerLoginModule|DatabaseServerLoginModule]]  flag="required">
     <module-option name="dsJndiName">java:/appDS</module-option>
     <module-option name="principalsQuery">select passwd from Users where username=?</module-option>
     <module-option name="rolesQuery">select userRoles as Roles from [[UserRoles|UserRoles]] where username=?</module-option>
    </login-module>
   </authentication>
  </application-policy>

/code Modificamos también el web.xml para que haga uso de los nombres de Roles especificados en la base de datos. 1. Integración de Apache (web server) con Tomcat-Jboss a traves del mod_jk Una de las características de la capa web de los servidores de aplicaciones es que suelen tener integrados un servidor web, además de los contenedores Pero suelen ser de más bajo rendiemiento que por ejemplo el servidor web apache. Por tanto se suelen configurar ambos servidores para que trabaje conjuntamente La idea es que la parte estática de una aplicación web la sirva el apache web server y la parte de servlets/EJBs el servidor de aplicaciones 1. Contenido estático vs contenido dinámico

Imagenes, js, html etc..
JSPs, Servlets

1. Protocolos (apj13, apj14) Existen varios protocolos definidos para poder realizar la comunicación entre ambos servidores.

apj13 (el mas usado actualmente)
apj14 (es una evolución del anterior
...

Además de poder utilizar este protocolo para descargar al servidor de aplicaciones de trabajo, se puede utilizar para balancear la carga desde un apache a varios servidores de aplicaciones.

- Configuración de los saltos entre el contenido dinámico y estático

[code|codeaptitude|install libapache2-mod-jk //hay que tener instalado el servidor apache2/code] Esto instala la libreria y una parte de la configuracion pero faltan 2 cosas

workers.properties
jk.conf

jk.conf lo creamos en mods-available/ con el siguiente contenido code# Where to find workers.properties JkWorkersFile /etc/apache2/workers.properties

Where to put jk logs JkLogFile /var/log/apache2/mod_jk.log
Set the jk log level debug/error/info JkLogLevel info
Select the log format JkLogStampFormat "%b %d %H:%M:%S %Y "
JkOptions indicate to send SSL KEY SIZE, JkOptions ForwardKeySize +ForwardURICompat ForwardDirectories # JkRequestLogFormat set the request format JkRequestLogFormat "%w %V %T"
Send servlet for context / jsp-examples to worker named worker1 JkMount /jsp-examples worker1
Send JSPs for context /jsp-examples/* to worker named worker1 JkMount /jsp-examples/* worker1

/code el workers.properties lo creamos donde hemos indicado, (jk.conf) con el siguiente contenido: [code]workers.tomcat_home=/usr/lib/apache-tomcat workers.java_home=/usr/lib/jdk ps=/ worker.list=worker1 worker.default.port=8009 worker.default.host=localhost worker.default.type=ajp13 worker.default.lbfactor=1 /code] Ajustando los parametros necesarios Desactivamos el modulo jk del apache2 y lo volvemos a activar para que linke el jk.conf. codea2dismod jk a2enmod jk /code 1. Ejemplo practico de aplicacion web 1. Estructura de un war 1. Ciclo de vida de una aplicación tipo war 1. Despliegue y ejecución de aplicaciones o Depliegue de aplicaciones Web 1. URL de interes sobre los temas tratados <table border="1">

 <tr> <th>Descripción</th> <th>URL</th> </tr>
 <tr> <td>Guia simple de instalación de Jboss en windows</td> <td>[http://javaejb.osmosislatina.com/jboss_windows.htm</td>] </tr>
 <tr> <td>Guia simple de instalación de Jboss en windowsEjemplos de ejb 3.0 para jboss</td> <td>[http://docs.jboss.org/ejb3/app-server/tutorial/index.html</td>] </tr>
 <tr> <td>Introducción a la programación orientada a aspectos</td> <td>[http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art152.asp</td>] </tr>
 <tr> <td>Jboss configuracion del class loader</td> <td>[http://wiki.jboss.org/wiki/Wiki.jsp?page] [[ClassLoadingConfiguration|ClassLoadingConfiguration]] /td> </tr>
 <tr> <td>Jboss class loader use case</td> <td>[http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossClassLoadingUseCases</td>]
 <tr> <td>JbossMQ</td> <td>[http://www.jboss.org/wiki/Wiki.jsp?page=JBossMQ] </td> </tr>

</table>

0 archivos adjuntos

3126 Accesos

Promedio (0 Votos)

Comentarios

zylk.net

zylk.net