J2EE (Solo expertos)

mouffetard dijo:

Que bueno sería que le pudieras hacer la consulta sobre el comportamiento de Coherence en Clusters y que nos de su opinión, así sea desde el punto de vista académico.

En estos momentos en la empresa para la que trabajo estamos enfrentando un problema de escalabilidad con una aplicación y lo hemos mitigado utilizando un cache centralizado, que se nos quedó corto porque no soporta distribución.

Haz clic para expandir...

Pues no prometo nada, ya que mis vinculos con la universidad ahora son minimos... Pero este profesor fue el director de mi tesis, y creo que podria hacerle unas consultas sin ningun inconveniente...

El sistema dentro de la universidad ya esta andando y hasta donde tengo entendido la ETB estaba muy interesada en invertir en esto y poner a andar algo similar.... No se nada muy profundo del proyecto...

mouffetard dijo:

Un tema que muchas veces se vuelve polémico, es el nivel que manejamos en el país en cuanto a diseño, utilizando herramientas como Patrones, UML, herramientas CASE, etc.

Por lo que conozco, por lo menos en Medellín y con algunos proveedores de Bogotá, nos falta todavía manejar con mucha más seguridad el tema. Un ejemplo: El patrón que utilizamos como lineamiento de arquitectura para aplicaciones web es MVC. Muchos proveedores no tenían ni la más remota idea de lo que era un patrón, y obviamente, mucho menos lo que era MVC.

No digo que no tengamos experiencia en desarrollo pues lo curioso fue que a algunos proveedores se les explicaba primero qué era el patrón MVC e inmediatamente reconocían la idea y decían que ya habían aplicado esa misma idea en otros proyectos. Otros, más numerosos, les pareció todo un avance la estructuración de una aplicación de esta manera.

¿Lo que quisiera saber es si en su experiencia utilizan los patrones de diseño como una herramienta común de comunicación entre arquitectos, diseñadores y desarrolladores, o si su uso es todavía incipiente?

¿Les parece que es importante su utilización como lengua franca, o por el contrario es una moda pasajera?

Yo creo que el uso de patrones como buena práctica es fundamental para sistematizar el conocimiento y la experiencia en la solución de problemas complejos y que sin lugar a duda, se debe empezar a exigir en el medio que todo proyecto explique, fundamentado en patrones de diseño, su propuesta arquitectónica y las soluciones encontradas en el diseño.

Haz clic para expandir...

A mi me parece muy importante el tema de los patrones y ese tipo de herramientas, pero con tristeza puedo decir que la gran mayoria de empresas que desarrollan lo hacen sin ninguna metodologia... al menos aqui en Bogota, en un sector donde se encuentran varias empresas de este tipo....

Tal vez las empresas un poco mas grandes tratan de mejorar estas practicas, pero lo que pasa en la mayoria de las ocasiones es que tienen un ingeniero que hace de todo.... en el ciclo de vida... y pues asi no se puede pretender nada bueno de estos desarrollos, al menos con respecto a Ingenieria de Software...

Es mas creo que ni siquiera en todas las universidades es una practica comun enseñar este tipo de cosas.. y mucha gente no sabe de su importancia...

Por mi parte me gustaria hacer un posgrado en este tema y tratar de traer esos conceptos mas fuertementes al mercado... tenemos que evolucionar y hacer las cosas bien hechas....

El problema que enfrentamos en la empresa donde estoy ahora es que se "casaron" con un patrón de diseño copiado de otra empresa, pero sin hacerle ningún tipo de modificación o adecuación.

Obviamente, para el desarrollo de la aplicación en la otra empresa, los requerimientos de escalabilidad y concurrencia eran demasiado altos y se escogió una modificación de MVC muy adecuada... pero ahora aqui tenemos baja concurrencia y cero escalabilidad... Entonces el modelo se le queda "grande" a lo que se necesita aquí.

Pero todo lo hacen por sacar el pecho y decir con orgullo que sus sistemas poseen "J2EE"... BAH.

Una forma de "Vender" el cambio

lemolina dijo:

En el ambiente empresarial donde me muevo, aunque el desarrollo utilizando patrones es todavía incipiente, se está empezando a cambiar la mentalidad de directivos de la organización con el fin de que le pongan más cuidado a esto.

Uno como simple ingeniero de desarrollo del área de IT de empresas de telecomunicaciones no se puede parar en las pestañas y exigir que las cosas cambien de la noche a la mañana, puesto que esas decisiones arquitecturales muchas veces implican cambiar, actualizar o hasta rediseñar aplicaciones que como bien dicen antes "se encuentran funcionando bien, no las toque!".

Y el choque generacional también es otro elemento con el cual nos toca luchar a los entusiastas de desarrollo J2EE... Personas que llevan 5 o más años administrando sistemas en SQL Server o Informix, todavia utilizando hasta interfases de texto que a uno le parecen risibles, son los que algunas veces tienen el poder decisorio en estas organizaciones y pues como dice el dicho "donde manda capitán, no manda marinero..."

De todas formas, hay que seguirlo intentando... yo por mi parte, trataré.

Haz clic para expandir...

La siguiente ha sido una forma de vender el cambio a nuevas tecnologías y enfoques, que de alguna manera ha sido exitosa. El cuento es que unos consultores de Cambridge nos echaron el cuento del City Plan. El concepto es muy sencillo: Cuando se planea una cuidad se tiene en cuenta que no se puede tumbar lo que ya existe, sino ir reubicando poco a poco, pero firmemente, los diferentes sectores de acuerdo a las potencialidades de cada lugar y a la concordancia entre elementos. De esta manera se crea un plan de gobierno y una "legislación" que logra que en lapsos medianos se avance hacia los visión ideal de la cuidad.

Aplicando este enfoque logramos, en dos años, implementar SOA y lograr compartir servicios entre las aplicaciones (C/S, .NET, Java).

Ojala puedas aplicar algo similar para vender la idea y convencer a los directivos y colegas de dar el paso hacia la innovación.

El_Rulas dijo:

¿Qué será mejor hacer? ... la ayuda debe ser capaz de buscar por palabras en el <content>, además tiene <keywords>.

3. Si hay otra idea mejor, ¿cuál sería?

---

Teniendo en cuenta lo de siempre: Buen desempeño, poca carga en memoría que sería lo mejor para hacer esto, que sugerencia me dan. Gracias.

Haz clic para expandir...

Lo que yo haria sería la generación de un índice de palabras que almacenaría en la base de datos, para cada palabra la referencia hacia los documentos que la contienen.

Tengo, por un lado, un proceso que descompone <keywords> y <content> en palabras y almacena la palabra y las referencias en dos tablas. El proceso lo haría off-line, pues no hace parte del OLTP de la aplicaciòn (supongo).

Por otro lado, tengo el componente de búsqueda, que se encargaría de recibir un conjunto de palabras y hacer las búsquedas sobre el indice de palabras. Para cada palabra obtengo la referencia y la referencia que contenga más números de palabras la califico con el mejor puntaje.

Una pregunta: Para esta soluciòn ¿En donde implementarian el algoritmo de búsqueda y de calificación de relevancia, en un EJB o en un SP?

El_Rulas dijo:

El contenido de las ayudas es estático, y por lo tanto es excelente la idea de tenerlo así, pero surge un problema con el algoritmo de calificación de relevancia: ¿cómo hago para no tener que leer todo los contenidos?.

Haz clic para expandir...

Yo igual, haría un query bien poderoso que me trajera la información lo más compacta posible y dejaría el resto del procesamiento para la capa media.

Lo de recorrer todo creo que no se puede resolver fácilmente porque precisamente eso es lo que se necesita hacer. Lo que pasa es que se hace de manera más o menos eficiente. Aquí es donde entra la mente de arquitecto y me hace pensar en que, por ejemplo, si las consultas son muy frecuentes, utilizaría un cache basado en base de datos para almacenar el resultados de las búsquedas más frecuentes.

El salón de informática de este años de ACIS tendrá especial énfasis en SOA. Creo que haré parte de los conferenciantes y me gustaría conocer sus opiniones al respecto.

¿Que opinan del paradigma?
¿Alguna solución ya en producción?
¿Qué dificultades, retos y beneficios les ha traído su implementación?
¿Quién cree que es pura carreta?
¿Cómo J2EE puede apalancar SOA? ¿Cómo lo dificulta?

Ha habido una controversia interesante en The ServerSide sobre la nueva versión de WebLogic, WebLogic Server 9.0. Por un lado, Gavin King, el creador de Hibernate asegura que BEA está quedándose rezagada porque no ofrece una implementación de EJB 3.0, mientras que JBoss si lo hace. El asegura que WebLogic está pendiendo el liderato en lo que se refiere a innovación.

Los representantes de BEA, por su parte, aseguran que es muy temprano para ofrecer su producto con una implementación de esta especificación. Que lo han hecho en el pasado y que de esa experiencia aprendieron que es mejor madurar la especificación para luego ofrecerles a sus clientes una solución estable. Ponen el ejemplo de las HomeInterfaces, que fueron una adición fundamental para poder establecer las relaciones entre EJB. También se defienden argumentando que lo que sus clientes han solicitado, son mejoras en la administración, la robustez y el monitoreo, y que finalmente, ese ha sido el enfoque de este nuevo release.

¿Qué opinan al respecto? Mientras que Jboss y Oracle ya ofrecen implementaciones de EJB 3.0, WebLogic se concentra en “robutez” ¿Es esta una jugada maestra para aliviar los dolores comunes de los clientes y afinazarse en un nico? O ¿Es acaso una jugada perdedora que los llevará a perder el liderazgo mundial como proveedor de servidor de aplicaciones J2EE?

Yo opino que un servidor maduro, como WebLogic, debe siempre tener en cuenta primero que todo la robustez de la plataforma y agregar características que disminuya el costo de propiedad y administración, logrando que los departamentos de IT ofrezcan un mejor servicios a sus clientes.

De otro lado, creo que empresas retadoras, tales como Jboss y Oracle, deben atacar por medio de la innovación, y que siguiendo esa línea, si BEA no se actualiza rápidamente liberando una versión Preview para desarrolladores con EJB 3.0, pederá gran parte del respeto en el ambiente de los desarrolladores y arquitectos J2EE.

¿Cuáles son sus opiniones?

Cabe aclarar que Gavin King es empleado de JBoss Inc. Es el creador de Hibernate y es uno de los miembros del Expert Group de EJB 3.0.

El_Rulas dijo:

¿Qué dicen ustedes?, ¿es tan descabellado lo que digo?

Haz clic para expandir...

Para nada descabellado....
Lo que pasa es que lo que le hace falta a las soluciones de software libre es que se crea mas en ellas, cuando se escogen soluciones con tecnologias propietarias la razon para hacerlo es el soporte que supuestamente hay detras de esto y como dije antes la poca credibilidad que tienen sus opositores...

es cuestion de la cultura.. creo yo!!!!!!! (hay que cambiar eso...)

Y cambiando un poco de tema...

Han oido de SiteMesh??? que opinan de este???

Yo creo que el costo hay que verlo desde varios puntos de vista:

El punto de vista de Costo Total de Propiedad (TCO). En este caso, cuando una empresa cuyo objeto social es diferente al desarrollo de software utiliza un producto, sea gratuito o licenciado por un valor, tiene que pensar en invertir en el mantenimiento del producto, en la capacitación de su personal o en el pago de un outsourcing para que realice esta labor. En plata blanca, no tengo idea que será más barato, porque no he tenido la experiencia de hacerlo, pero intuyo que puede ser más barato a corto plazo una alternativa gratuita frente a una alternativa con costo de licenciamiento. Esta afirmación la sustento en que el conocimiento de herramientas comerciales en Colombia está mucho más maduro que el conocimiento en herramientas sin costo de licenciamiento, por lo menos en el medio en el que yo me desempeño.

El punto de vista del costo de “Salvarse el pellejo”. Cuando ocurre un problema, por ejemplo de infraestructura, que afecta a toda una compañía y por ese motivo deja de facturar millones, lo primero que hace el gerente de TI es ir a donde el responsable de la plataforma y exigirle que solucione el problema. Si el responsable de la plataforma tiene que cacharrear para solucionar el problema entonces su pellejo está en riesgo. Si este persona cuenta con un soporte de una empresa reconocida, lo que está en riesgo es el pellejo del proveedor del producto. Esto suena demasiado feo, pero es la realidad y lo he visto ocurrir muchas veces.

Desde el punto de vista de la “percepción de confianza”. En las empresas que no se dedica al desarrollo de software, las decisiones sobre adquisición de tecnología se hacen, con mucha certeza, de acuerdo con la percepción que se tiene de la solidez de la compañía que provee el producto. Inclusive, en las matrices de evaluación de productos, con mucha frecuencia, se solicita referenciación y más crítico aun, se solicita el PyG. Por estos motivos, la percepción de confianza en productos “open source” es mucho meno comparado con productos “propietarios”.

En mi opinión, a corto y puede que a mediano plazo, una solución sin costo de licenciamiento tiene una ventaja económica, pero a largo plazo puede resultar mucho más costosa. Puede, inclusive, que al final del día tenga que pagar una consultoría a un experto internacional (tipo Jboss Inc.) para que venga a solucionarle el problema, si es que todavía está trabajando en la empresa.

Bueno parece que este tema se cerró. Que lástima que no hayan más comentarios así sean básicos, pues de todos se aprende mucho.

No sé si sea conveniente, por ejemplo, plantear temas mas practicos y básicos, problemas con los que nos encontramos en el día a día.

¿Qué opinan?

Si! que pasa muchachos, no dejen morir el tema , esta bueno...

Bueno ahora mirando las novedades que se presentan, mucha gente ha comenzado a hablar de los POJOS, si algo que en teoría y al parecer en la práctica es mejor y resuelve algunas deficiencias de los EJB´s asi que habra que mirar que sucede...

Los POJOS es el enfoque que he seguido siempre. Significa "Plain Old Java Objects". Para la mayoría de las palicaciones pequeñas es overkill ponerse a hacer todo lo de los EJB, sale más fácil y rápido un piche objetico java...

Si, me parece excelente el nuevo enfoque, sobre todo apalancado en frameworks de persistencia mucho más simples y eficientes (hibernate, toplink y asociados) que no requieren implementaciones complejas. EJB 3.0, de acuerdo con lo que he leído, se basa en POJOs o por lo menos simplifica enormemente el desarrollo de los Entity. Inclusive, existen servicios de persistencia por fuera del contenedor.

Otro beneficio importante de este enfoque, es que se facilita enormemente el desarrollo de pruebas unitarias, pues los POJOs pueden probarse sin tener que iniciar el contenedor y hacer todo ese ciclo largo de inicialización, deployment, pruebas, shutdown, corrección, compilación y vuelve y juega.

Como bien lo dice El_Rulas, mientras los requisitos no funcionales del sistema lo permitan es mucho mejor mantener la arquitectura lo más simple posible.

De todas maneras recomiendo precaución con los frameworks de persistencia, pues mientras no se dominen bien, es muy arriesgado (hablando comercialmente) iniciar un proyecto con estas soluciones. Hoy mismo me comentaron un caso de un proyecto mediano que decidió irse por hibernate y en estos momentos está en problemas.

No es que el framework sea malo, por el contrario, es muy bueno. Lo importante es que los diseñadores y desarrolladores del sistema tengan suficiente experiencia para lograr sistemas eficientes y robustos.