Guía estratégica de migración de WAS a JBoss

knowgate
Guía estratégica de migración de WAS a JBoss

Esta presentación contiene la guía estratégica para la migración de IBM WebSphere
a JBoss Enterprise.
El cambio de tecnología reporta habitualmente los siguientes beneficios:
1. Menor complejidad, menos tiempo empleado en gestión de servidores.
2. Mayor facilidad de instalación y configuración.
3. Reducción del coste total de propiedad.
4. Mejor productividad en programación gracias a la integración con tecnologías Web 2.0.
5. Configuraciones de alta disponibilidad con balanceo de carga tolerantes a fallos.
6. Uso de estándares Open Source.
Contenido de esta presentación

Factores decisivos para una migración
Cada compañía decide migrar de un servidor de aplicaciones a otro por diferentes motivos.
Los más comunes son los siguientes:
•Reducir el Coste Total de Propiedad
•Reducir el coste del soporte
•Eliminar licencias por CPU
•Poder empaquetar el servidor con otro software para distribuirlo todo junto
•Permitir el uso de hardware más barato
•Permitir el uso de clusters más robustos
•Expandir granjas de servidores
•Adherirse a estándares
•Consolidar el centro de datos
•Adoptar de metodologías de desarrollo rápido
•Ganar Flexibilidad
•Mejorar el Rendimiento
•Aumentar la Escalabilidad

6 pasos esenciales de planificación
1. Examinar todas las funcionalidades utilizadas en WebSphere y determinar su equivalencia en
JBoss.
2. Específicamente para las funcionalidades exclusivas de WebSphere definir una forma alternativa
de hacer lo mismo con JBoss.
3. Medir el grado de preparación en la empresa para una migración.
4. Estimar el riesgo total de la migración detallando punto por punto.
5. Desarrollar un plan táctico de migración con un roadmap detallado y un cálculo de costes.
6. Definir el servicio y soporte durante y después de la migración.

Módulos de JBoss Enterprise
EJB 3.0 Portal
AOP JGroups
Hibernate MQ
Cache Messaging
IDE Mail Server
jBPM Tomcat

Migración de aplicaciones web básicas.
Migración de Java EE
Migraciones de JSR
Migración de la configuración
Escenarios de Migración

Migración de aplicaciones web básicas
Migrar aplicaciones web básicas que están desarrolladas de acuerdo a las especificaciones de servlets y Java EE es la manera
más sencilla y práctica de empezar a experimentar con el cambio a JBoss Enterprise. Suelen dar una buena métrica del esfuerzo
requerido. Si la aplicación a migrar está desarrollada con un IDE como Eclipse o Netbeans el cambio normalmente es bastante
fácil y rápido. Otros IDEs gestionan las librerías de forma que pueden dar algo más de trabajo hasta resolver todas las
dependencias.
El descriptor de despliegue web.xml de cada webapp puede contener tags propietarios que no sean reconocidos por JBoss.
Asimismo, los descriptores propietarios adicionales ibm--web--ext.xmi e ibm--web--bnd.xmi deben ser convertidos al jboss-
web.xml reconocido por JBoss.
Muchas aplicaciones web se pueden copiar directamente de WebSphere a JBoss sin hacerles absolutamente ningún cambio.
Cuando se requieren cambios, los obstáculos más frecuentes suelen ser.
1.En general, hay que copiar archivos .war y no directorios expandidos, pues estos últimos tienen tendencia a dar problemas.
2.Los descriptores .xmi la mayoría de las webs no contienen información relevante para el despliegue, pero cuando sí la
contienen, como el context root o restricciones de seguridad, entonces hay que convertirlos a jboss-web.xml.
3.Las webapps pueden usar librerías propias de WebSphere, sobre todo librerías de tags JSP. Aquí la migración se pueden
complicar. Dependiendo de la librería en cuestión, no siempre es trivial encontrar un componente Open Source con la que
reemplazarla directamente.

Migración de Java EE
En teoría, la migración de Java EE no es más complicada que la de aplicaciones
web. No obstante, el propósito de las especificaciones Java EE es facilitar la
integración de múltiples frameworks con funcionalidades diversas. Esto suele implicar
que en un entorno Java EE existan muchas mini-aplicaciones involucradas. El
proyecto MASS de JBoss proporciona una herramienta de análisis de migración
llamada MAT que scanea el código fuente de las aplicaciones en busca de librerías
propietarias. Este análisis de MAT proporciona información muy valiosa a la hora de
estimar el esfuerzo requerido para la migración de aplicaciones Java EE.

Migraciones de JSR
JSR es una iniciativa de la comunidad Java para estandarizar áreas cómo:
portal, ESB, workflow, inyección, etc.
En JBoss existen diferentes caminos de migración para cada estándar JSR.
Dependiendo de lo completa que sea la especificación en cuestión, la
migración puede ser muy simple o realmente complicada. En general, las
anotaciones son más estándar que las implementaciones XML.

Migración de configuración
A grandes rasgos, un entorno WAS está organizado en una serie de celdas y
nodos. Un nodo se define por un repositorio de configuración y un único perfil.
Varias instancias WAS pueden pertenecer al mismo nodo, sin embargo, cada
instancia sólo puede pertenecer a un solo nodo. Los nodos son gestionados por un
agente en el cual el nodo se registra. Pero en otros entornos más sofisticados en
gestor de despliegue es usado para administrar y gestionar y provisionar con
eficiencia los nodos. Por último, un planificador de tareas puede ser usado para
enviar de forma asíncrona tareas administrativas a los gestores de despliegue y a
los agentes administrativos.

Servicios configurados
WAS maneja los conceptos de aplicaciones instaladas y servicios configurados, con un ámbito en el
nivel aplicable. Los recursos en la terminología WAS pueden incluir fuentes de datos JDBC y
destinos JMS, que se consideran artefactos desplegables en JBoss. Esto induce a dos modelos
muy diferentes entre WAS y JBoss.
Con WAS, los servicios JDBC y JMS se configuran a través de la consola de administración de
WebSphere. Esto es así tanto para desarrollo como para producción, con lo cual el propio
desarrollador puede ser el administrador del entorno de producción. Aunque la configuración de los
recursos depende en última instancia de las necesidades de cada aplicación, dicha configuración
está físicamente separada de la aplicación en sí misma. Los desarrolladores suelen documentar las
dependencias de servicios y los administradores siguen dicha documentación para configurar los
servicios de manera que las aplicaciones funcionen correctamente.
Por otro lado, con JBoss cada servicio se configura en su propio fichero XML. Dos o más servicios
del mismo tipo se pueden configurar en el mismo fichero XML. Esto da a los usuarios flexibilidad en
la elección de su configuración. Con Jboss se pueden seguir las mismas prácticas de configuración
de servicios que con WAS basadas en leerse la documentación de los desarrolladores. Pero con
JBoss también es posible incluir ficheros XML redistribuibles dentro del archivo de distribución, lo
cual permite crear aplicaciones autocontenidas que incluyen sus propias dependencias de
configuración.

JDBC
En WebSphere cada fuente JDBC se configura en su propio fichero XML correspondiente al
perfil y ámbito. El patrón típico es crear un directorio para cada perfil bajo
WebSphere/AppServer/profiles/ Este directorio contendrá otro subdirectorio /config/ que a su
vez contendrá la jerarquía de subdirectorios correspondientes al ámbito aplicable a la fuente a
la fuente de datos. Por ejemplo, si la fuente de datos se aplica a nivel de celda entonces un
subdirectorio llamado /cells/ contendrá un subdirectorio para dicha celda el cual tendrá un
fichero resource.xml descriptor de la fuente de datos. Una fuente de datos definida bajo un
proveedor JDBC estará en el elemento factories del fichero de configuración con tipo
resources.jdbc:DataSource bajo resources.jdbc:JDBCProvider. Puede haber también otras
propiedades en fichero XML tales como las necesarias para el configurar el pool de conexiones.
En JBoss basta con crear un snippet XML datasource para cada pool de conexiones que figura
bien en su propio poolName-ds.xml bien combinado colectivamente en el mismo fichero *-
ds.xml. El contenido de dicho fichero XML para la fuente de datos JDBC dependerá del
comportamiento transaccional del datasource así cómo de los detalles de su conexión. Todos
los detalles sobre la conexión del *-ds.xml en JBoss se encuentran en WebSphere en el
correspondiente fichero *-jdbc.xml bajo config/jdbc. La contraseña de la BB.DD. se guarda
encriptada y, por consiguiente, no es en general posible automatizar al 100% la migración.

JMS
En WebSphere cada componente JMS se configura separadamente en la consola de
administración. Por ejemplo, los proveedores JMS se crean y configuran en una sección
separada de los destinos tales como colas y tópicos, aunque en el fichero XML donde se
refleja esta configuración los destinos aparecen bajo el proveedor aplicable. Esta información
se almacena en un fichero XML correspondiente al perfil en el nivel de ámbito que sea. El
patrón típico es es que exista un directorio por perfil bajo WebSphere/AppServer/profiles y
que este directorio contenga subdirectorios correspondientes al ámbito al que se dirige el
componente JMS. Por ejemplo, si una cola se dirige al nivel de celda, un subdirectorio
llamado /cells contendrá un directorio para dicha celda que a su vez tendrá un fichero
resources.xml descriptor de la cola JMS. Una cola ligada a un proveedor JMS aparecerá en
el elemento j2cAdminObjects bajo el proveedor JMS el cual se describe en el elemento
J2CResourceAdapter.
En JBoss las factorías de conexiones JMS se configuran típicamente en deploy/jboss-
messaging.sar/connection-factories-service.xml pero, en general, se pueden configurar como
parte del fichero de despliegue de cualquier servicio. En JBoss basta con crear un snippet
XML de destino JMS para cada cola o tópico el cual puede venir en su propio fichero
destination-service.xml o combinado colectivamente en el mismo *-service.xml. El contenido
de tal fichero destination-service.xml se parece al de cualquier fichero de despliegue MBean
siendo el código Mbean QueueService o TopicService según requiera cada caso. El fichero
XML se puede desplegar en el servidor JBoss dejándolo en el directorio /deploy.

Clustering
Aunque las funcionalidades son bastante parecidas, existen diferencias significativas en la
forma en la que se configura el clustering en WebSphere vs. JBoss. WebSphere
proporciona una visión del cluster que es muy estática tanto en lo referente a los
miembros como en sus detalles de configuración que son limitados y, básicamente,
convierten al cluster en una caja negra. Esto lleva a un nivel de simplicidad que puede ser
bueno para algunas instalaciones pero crear quebraderos de cabeza en otras. El cluster
en sí mismo se define de forma estática en el servidor de administración con direcciones
explícitas para cada miembro.
En JBoss el cluster es un concepto mucho más dinámico. Se define por un nombre de
cluster y una dirección unicast o multicast. Cualquier instancia de JBoss que pretenda
unirse al cluster puede hacerlo comunicándose con su dirección y dando el nombre del
cluster. Esto proporciona una forma muy fluída de definir un cluster que es útil para ir
provisionando nuevas instancias. Además, el clustering de JBoss está montado sobre
JGroups que es muy configurable. Se soporta una gran variedad de topologías de red y, si
se sabe hacer, se puede optimizar mucho más el rendimiento del cluster de lo que es
factible en WebSphere.

Cache
En un cluster los caches deben mantenerse sincronizados para evitar problemas de integridad de
datos. Los más prominentes son el cache de sesiones HTTP y los caches de entity beans. De
nuevo, WebSphere toma un acercamiento de caja negra mientras que JBoss tiene un enfoque más
abierto y parametrizable montado sobre una pila de software libre.
JBoss Cache se utiliza para proporcionar un cache distribuido transaccional para entity beans y
sesiones HTTP. Algunas características avanzadas tal como la replicación mediante AOP no basada
en serialización está disponible en JBoss dentro de las funcionalidades de para POJOs. El protocolo
de comunicación también se puede cambiar , así como la replicación síncrona o asíncrona.

JVM y CLASSLOADERS
A pesar de que existen diferencias de implementación entre las diferentes máquinas virtuales, nosotros hasta la fecha
no nos hemos encontrado aplicaciones que puedan correr en una pero no en otra, excepto por el propio JBoss que
requiere una JVM específica para cada versión. En general, casi siempre montamos Sun Java ya que Open JDK nos
ha dado algún problema de compatibilidad en el pasado.
Lo que sí hemos detectado que funciona de forma muy diferente en WbSphere vs. JBoss son los classloaders.
Algunas aplicaciones dependen de forma inadvertida del funcionamiento del classloader. WebSphere proporciona un
classloader jerárquico cuyo comportamiento estándar es delegar en el padre. Tras la JVM, y las librerías WAS la
jerarquía eventualmente llega a la aplicación. Cuando las webapps existen dentro de aplicaciones enterprise se les
asigna su propio classloader hijo del classloader del enterprise. JBoss en cambio usa un modelo mucho más simple,
en el cual la mayoría de los artefactos residen en un único classloader que es altamente parametrizable y que puede,
potencialmente usar un classloader compartido.

Latencia y volumen de
peticiones
En general, los servidores se optimizan bien para tener bajos tiempos de latencia bien para proporcionar un
elevado throughput. La parametrización de timeouts, número máximo de hilos y otras opciones están en el
espectro opuesto cuando se trata de minimizar la latencia o de aumentar el throughput.
Cuando se persigue aumentar el throughput la prioridad es el rendimiento global del sistema sin prestar
demasiada atención a los tiempos de respuesta a peticiones individuales. Por ejemplo, para un servidor con
cuatro núcleos se puede determinar que 200 peticiones concurrentes es el punto óptimo para tener un tiempo
medio de respuesta de un segundo. En una configuración orientada a maximizar el throughput se limitaría el
número de hilos a 200 y el resto de peticiones concurrentes que llegasen por encima de esa cantidad se
encolarían lo cual provocaría que se ralentizase el tiempo de respuesta a determinadas peticiones. Al tratar de
maximizar el throughput podría ser que se viole un SLA que diga, pongamos, que el tiempo máximo de respuesta
debe ser de 2 segundos. Para reducir la latencia se podría aumentar el número máximo de hilos de 200 a 300,
eso podría provocar que el tiempo medio de respuesta fuese de 1,7 segundos y con ello cumplir el SLA, aunque
el rendimiento global del sistema habría pasado de 200tps a 176tps.

Separación del servidor web
del servidor de aplicaciones
- Algunas empresas especializadas en middleware recomiendan
separar el servidor web del servidor de aplicaciones. En nuestra
experiencia, esto puede ser útil en algunos casos, pero en la mayoría
de ellos añade un nivel de complejidad innecesario, además de
complicar la configuración debido a la proliferación de servidores
físicos.
- Si se usan máquinas virtuales de 32 bits suele ser mejor limitar a una
las aplicaciones por cada servidor de aplicaciones debido a la
restricción a 4Gb de RAM. En 64 bits, sin embargo, se suelen
aprovechar mejor los recursos computacionales desplegando varias
aplicaciones en cada servidor.
- También es posible instalar varias instancias de JBoss en la misma
máquina.
- Respecto de las sesiones HTTP, nosotros recomendamos mantener el
mínimo de información en ellas para que los caches funcionen más
eficientemente. Lo ideal son aplicaciones web que no mantengan
estados, dado que ello hace innecesaria la replicación.

Migración de hardware I
Aunque Java es muy transportable, a veces se encuentran aplicaciones con funcionalidades ligadas al sistema
operativo o hasta al hardware.
Los tres escenarios típicos de migración son: consolidación (juntar varios servidores físicos en uno), dispersión o
agregación. En principio, un menor número de servidores implica menos esfuerzo de administración, aunque si la
consolidación se hace mediante máquinas virtuales en nuestra experiencia pueden producirse sorpresas
desagradables con el rendimiento, en especial si las máquinas virtuales están provisionadas mediante un servicio
cloud de un ISP.

Migración de hardware II
Si se contempla cambiar el hardware conviene estudiar previamente los siguientes
puntos:
1.¿Es la aplicación de misión crítica?
2.¿Cómo son de críticos los datos? ¿Qué redundancia requiere el almacenamiento?
3.¿Qué acuerdos de nivel de servicio (SLA) deben cumplirse?
4.Qué topología de red se adapta mejor a las necesidades de comunicación?
5.¿Cuánto ancho de banda se necesita?
6.¿Qué tipo de cache debe implementarse en JBoss?
7.¿Existe un punto óptimo entre latencia versus throughput?
8.¿Qué otras optimizaciones convendría hacer en JBoss?

El proceso de migración paso a paso
Fase Descripción Entregable Duración
I) Modelo de arquitectura y
despliegue
Inventario de servidores,
infraestructura de red y
aplicaciones. Planificación de
capacidad.
Inventario de servidores de
aplicaciones, su propósito.
Hardware y otros recursos
computacionales.
2 semanas
II) Análisis de aplicaciones Análisis de las aplicaciones una
por una. Dependencias, librerías,
peculiaridades.
Lista priorizada de aplicaciones
que se pueden migrar. Inventario
de librerías usadas y
dependencias. Especificaciones
de la migración
De 2 a 8 semanas
III) Estimación de esfuerzo y
riesgo.
Detalles de configuración de
cada servidor y aplicaciones.
Lista de servicios configurados
por servidor. Clusters. Esfuerzo
estimado de migración.
Identificación de riesgos
principales.
4 semanas
IV) Plan de migración Plan de trabajo detallado para la
migración. Roadmap. Recursos
asignados.
Documentos de instrucciones
detalladas para migrar los
servidores y las aplicaciones
seleccionadas
5 semanas
V) Migración Implementación de cambios Aplicaciones reinstaladas y
operativas
Depende de la cantidad de
aplicaciones

Fase I:
Modelo de arquitectura y despliegue
En esta fase se hace un inventario de los servidores existentes, la infraestructura de red y las
apps.
La infraestructura comprende el ecosistema completo:
Centros de datos: Cuántos hay. Cual es su misión. Cómo están interconectados. Cual es la
estrategia de tolerancia a fallos.
Hardware: Servidores. Balanceadores de carga. Routers. Almacenamiento en red.
Software base: Servidores web. Servidores de aplicaciones. etc.
Servicios de soporte: Mensajería, portal, AOP, inyección, cache, etc.
Entornos de desarrollo: IDEs, gestión de la configuración, scripts, bug trackers.
Aplicaciones: Listadas por servidor, funcionalidad y grado de criticidad.

Fase II:
Análisis de aplicaciones
Con el fin de estar al tanto de todo el ámbito de la migración, es importante evaluar qué tecnologías
están siendo utilizadas por las aplicaciones. La típica aplicación hace uso de varias
tecnologías para la seguridad, el almacenamiento en caché, la inyección, etc. Estas tecnologías
están en gran medida ocultas al desarrollador y podrían no ser conscientes de ellas, pero pueden
tener un impacto importante en el rendimiento y la escalabilidad.
El no poder planificar la migración de estas tecnologías puede crear graves problemas. Además,
estos problemas generalmente surgen al final de un proyecto de migración en las pruebas de
rendimiento se llevan a cabo.
Un análisis esencial es la identificación de librerías propietarias usadas por la aplicación. JBoss
proporciona el Migration Analysis Tool (MAT) para estimar la cantidad de código propietario que
habrá que migrar a alternativas Open Source.

Fase II:
Mapeo común de aplicaciones
Componente Funcionalidades JBoss EAP
Monitorización y Management Control remoto y configuración,
alertas.
Consola de administración JBoss,
interfaz JMX, alertas.
Servidor Web Contenedor de servlets, replicación
de estado.
Tomcat, replicación.
Mensajería JMS. Persistencia de mensajes.
Puentes entre clusters.
JBoss messaging
Cache Transaccional. Distribuido. Grafos. JBoss cache, replicación.
Clustering Replicación transaccional. JBoss cluster, JGroups.
Persistencia BB.DD. Sistemas de ficheros.
Almacenamiento no relacional.
JDBC, connection pooling,
Hibernate.
Seguridad Autentificación. Single sign-on.
JAAS. JACC. Certificados.
JAAS, LDAP, SSO.
AOP Cross-cutting concerns JBoss AOP.
Inyección Soporte estándar de inyección Estándares de inyección JEE.
JSP, JSF, Facelets, tags Compatibilidad y soporrte para los
estándares de presentación
Soporte de estándares comunes
Transaction Manager Transacciones fiables, distribuidas JBoss transactions

Fase III:
Estimación de esfuerzo y riesgo técnico
Tras estudiar la arquitectura de despliegue y el inventario de aplicaciones y tecnologías a migrar, se
está es disposición de estimar el esfuerzo y riesgo de la migración. Factores para los cuales se debe
medir tanto la parte técnica como la organizativa. Enfocándose en los siguientes puntos:
1.Análisis Técnico
• Ámbito
• Nº de servidores, centros de datos y aplicaciones a migrar
• Análisis del «technology gap».
• Funcionalidades que no se mapean de forma natural a componentes Open Source
• Requerimientos conflictivos de configuración
• Adhesión a estándares
• Uso de IDEs propietarios que usan librerías propias
• Selección de librerías

Fase III:
Estimación de riesgo organizativo
Con frecuencia, los factores organizativos son más difíciles de prever que los técnicos. Es relativamente sencillo
definir y tratar problemas técnicos. Mas los factores organizativos tienden a ocultarse bajo la superficie de una forma
en la que aparentes pequeñeces pueden convertirse en barreras infranqueables. Cuando esto sucede, la empresa
acaba más preocupada de los inconvenientes a corto plazo que de los beneficios y oportunidades a largo.
2.Análisis Organizativo
• Necesidades de formación y conocimientos
• Tendencia espontánea del staff a cambiar
• Procesos actuales de desarrollo y despliegue
• Carga de trabajo general con proyectos y soporte
• Capacidad para acometer el sobreesfuerzo de la migración
• Disponibilidad de suficiente hardware para las pruebas y la migración
• Jerarquía y procedimientos para la toma de decisiones
• Consideraciones de calidad versus coste
• Contratos existentes con proveedores
• Métricas financieras: CAPEX, OPEX, TCO, ROI
• Balanza de poderes en la organización

Fase III: DAFO (ejemplo)
DebilidadesDebilidades
OportunidadesOportunidades
AmenazasAmenazas
FortalezasFortalezas
• Bajo presupuesto
• Sobrecarga de trabajo
• Entornos de desarrollo propietarios
• etc.
• Procedimientos complejos de despliegue
• Imposibilidad de hacer ningún cambio hardware
• Presupuesto cero para formación
• etc.
• Staff con mucha experiencia
• Fuerte compromiso gerencial
• Todas las apps en formato WAR o EAR
• etc.
• Reconfiguración dinámica de servidores
• Introducción de nuevos estándares
• Simplificación de licencias

Fase III: Plan de Contigencia (ejemplo)
Riesgo Probabilidad Impacto Plan
Deficiente Formación Alta Alto Reasignar parte del
presupuesto de
soporte a horas de
formación
Insuficientes
servidores para
pruebas
Media Medio Sistemas cloud en
alquiler por uso
Entornos de trabajo
propietarios
Media Alto Emplear todo el
tiempo que sea
necesario en análisis
de librerías y
dependencias.

Fase IV: Plan de Migración
Una vez que se ha evaluado el esfuerzo y el riesgo hay que definir los Entornos Operativos Estándar de origen y
destino. Debe estar perfectamente definido sin ninguna ambigüedad qué componentes habrá en cada entorno
incluyendo la versión exacta de cada uno de ellos. En algunos casos, puede que se requieran más de dos entornos
operativos, aunque siempre se debería tratar de mantener la variedad de configuraciones en el mínimo posible.
Una vez que se tienen los Entornos Operativos Estándar hay que definir la configuración de origen y destino para
cada aplicación.
Lo siguiente es hacer un cálculo de costes sobre lo siguiente:
•Cuánto cuesta el hardware necesario para la migración y durante cuánto tiempo hará falta.
•Cuánto cuesta desarrollar extensiones para reemplazar software privativo que se dejará de usar.
•Estimación de las horas hombre necesarias por aplicación, en función sobre todo de si únicamente requieren
cambios en la parametrización o por el contrario es preciso tocar también el código fuente.
•Cuánto cuesta la formación.
•Cuántas horas y personas habrá que emplear en reuniones y revisiones de proyecto.
•Quién fijará y controlará los hitos de migración.
•Cual será el protocolo de escalado de incidencias.

Fase V: Migración
La migración en sí misma se planifica y gestiona mediante técnicas y herramientas
estándar de gestión de proyectos de desarrollo y despliegue de software.
Todas las buenas prácticas de gestión de proyectos son, en general, aplicables, siendo
preferibles, por ejemplo, los hitos relativamente cortos con revisiones frecuentes de
desviaciones, colocar las tareas más largas y de mayor riesgo al principio del proyecto,
llevar el mínimo de proyectos en paralelo asignados a los mismos recursos humanos, ir
consiguiendo pequeñas victorias técnicas y organizativas, etc.

Guía estratégica de migración de WAS a JBoss

Más contenido relacionado

Destacado

Similar a Guía estratégica de migración de WAS a JBoss

Último

Guía estratégica de migración de WAS a JBoss