J2EE (Solo expertos)

[Sponsored links]

[Grissom.]

Hay muchos temas avanzados que tratar, no sé que tan llena esté la comunidad de conocedores J2EE, pero hago este foro para los que desarrollamos encerio.

A continuación voy a colocar unos puntos, no son afirmaciones, son las cosas que actualmente uso para desarrollar mis aplicaciones, por supuesto está abierto a sugerencias, y decir que se está haciendo mal, si se conoce alguna herramienta que hace mejor el trabajo que estas.

1. La mejor combinación gratuita para desarrollar:

* Sistema operativo: Linux
* IDE: Eclipse (desarrollo Java puro)
* Desarrollo de EJB, generación de interfaces Remota / Local, Home, descriptores ejb-jar.xml y especifico del application server, Ejem jboss.xml: XDoclet
* Compilación y generación de JAR EJB, utilitarios, WAR, EAR: ANT
* Páginas Web: JavaServer Faces 1.1 (MyFaces??)
* Application Server para desarrollo: JBoss (cómo se porta en producción??)
* Base de datos: Postgres, Mysql ... excelente soporte de drivers JDBC y pool de conexiones !

2. ¿Quién ha trabajado en una solución para integrar Struts-Tiles con JSF, teniendo en cuenta que JSF no tiene soporte para Tiles?? ...

De momento tengo esta solución: http://www.jsftutorials.net/tiles/jsf-tiles.html propuesta por el grupo Exadel (Fabrican plugins para eclipse creo ... la solución de este árticulo es estándar Java no requiere nada de ellos en particular).

Hay una solución hecha por IBM pero requiere integrar con el controler de Struts, pero no la veo viable porque el de Faces es más simple.

3. La solución a las librerias (Thirdparty):

Este problema común, cuál será la mejor manera de tener estas librerias? ...
* En el directorio LIB de cada WAR; EJB pegarlas y asi las coje al vuelo.
* Esta es la que tengo de momento: Las coloqué en el directorio LIB del EAR, y en cada archivo META-INF/manifest.mf de cada WAR; EJB hice una referencia:

Class-Path: lib/struts.jar lib/commons-lang.jar ....

Lo tedioso es hacer estas referencias, pero la escojí por que las librerias quedan en un solo sitio, y el proyecto EAR queda mucho más pequeño, además no hay riesgos de conflictos.

Lo que estoy diciendo puede ser falso, verdadero, puede haber otras opciones más viables para todo, de eso se trata el foro.

Te invito a participar.

[supernaut00]

A mi me gusta la combinación Jdeveloper 10 con BD Oracle.. excelentes..

[kemark]

podrian hacer una comparacion entre usar programas libres como los que propone rulas y programas comerciales comerciales como los que propone supernaut00 (Costo/Beneficio) ?

[Grissom.]

Lo que he visto en estos paquetes para desarrollo Oracle, BEA es que dinero invertido es bien grande, además se necesitan maquinas para desarrollo bien potentes, los requerimientos de memoria y procesador se vuelven altísimos en la medida que el proyecto crece, aquí no es tan fácil meterle un ANT para que las cosas se construyan rápido, estos motores por debajo replican todo.

Otra cuestión que no me gustó mucho fue el matrimonio con la compañia, las cosas solo sirven para su Application server, y hasta los .jar están licenciados.

La curva de desarrollo en inicio con las pantallas iniciales, y las cosas simples es impresionante hay que admitirlo. Por ejemplo el framework de BEA es click, click ... personalmente, pienso que en este tipo de programación siempre hay perdida de control en gran medida ... veamos que opiniones hay por acá.

[greenal]

Lo ke dice Krawek es cierto, y personalmente prefiero una base de datos en postgresql ke es mucho más facil de manipular, ke una base de datos en Oracle (ademas ke no se ni cu..), igual como desarrollador es más facil sustentarle a un gerente ke es mas conveniente trabajar con software libre pk es mas económico. Igual el Rulas tiene razon, eso de siguiente, siguiente, siguiente es demasiado debil pk ud no puede reestructurar lo ke existe por debajo en comparación con el open source.

Y creo ke la mayoria de los ingenieros vamos a llegar en unos pocos años a preferir si es ke ya no es asi en un 90% de la población ingenierial herramientas libres.

[will_23]

Bueno...
pues a mi me gusta mucho la programacion con Struts, Hibernate y Spring...

todo esto sobre Tomcat y base de datos MySQL desarrollando sobre Eclipse....

Esto es muy bueno porque permite implementar Un patron de diseño llamado MVC y las aplicaciones quedan muy bien estructuradas, aunque aprender a manejar estas tecnologias es un poco demorado.. Pero vale la pena.

[jindix]

Hola LANeros!

Lo que proponen El_Rulas es fabuloso, yo trabajo desde hace 3 años con Java y la verdad le debo todo lo que tengo aunque es poco Je, je je...

Ojalá haya más gente que conzca de verdad el tema y podamos trabajar conjuntamente, aqui tienen a un servidor a la orden. Ahora si paso a contarles...

Actualmente trabajo como Freelance y tambien en varias empresas, desarrollo aplicaciones j2EE básicamente con las herramientas mencionadas:

Eclipse, JBoss, tomcat, Struts, XML, JSF´s, eso si veo que les hace falta conocer o no se si la conozcan esta herramienta "Lomboz", excelente para agilizar el desarrollo de j2EE:
http://www.objectlearn.com/index.jsp

A veces uso el JBoss IDE. es bueno tambien ademas los 2 soportan edición JSP, XML, XHTML, y más:
http://www.jboss.org/products/jbosside

En producción he notado un excelente comportamiento tanto en JBoss como en tomcat(tambien viene dentro de JBoss) y encuanto a motores de Bases de Datos prefiero todo lo que sea Open Source es decir PostgreSQL, dado que hace unos dias tuve un pequeño inconveniente con MysQL, resulta que si uno lee toda la letra menuda de los terminos de uso de MySQL se da cuenta que no es tan Free como se supone...

Bueno en estos dias les sigo contando aceca de los proyectos que estoy trabajando y haber si por fin despega nuestra comunidad....


SUERTE Y JAVA FOREVER!!!!!!!

[Grissom.]

Lomboz es un plugin para eclipse, realmente lo que hace es XDoclet ... la verdad no es mucha ventaja que escribir uno mismo el XDoclet, es hasta más rápido, igual los tags XDoclet son autocompletados ....

El generador XDoclet uno lo corre desde ANT y listo ... mejor dicho, estas herramientas realmente sirven para quienes no conocen XDoclet ... XDoclet es lo más portable que he visto para generación de descriptores e interfaces EJB Remota/ Local, Home ...

JBoss IDE Trabaja similar a Lomboz, es exclusivamente orientado a JBoss, si tienes un build.xml de ANT generando los descriptores estándar, decirle que te genere uno para JBoss hay de paso, es cosa de una línea XDoclet ;) ....

Hibernate 3 es la berraquera ! ... lo que noto es que la mayoría aún usa simplemente Tomcat, vayan pensando Enterprise ... tengan en cuenta que Tomcat es un complemento perfecto para los application servers, hasta Webphere lo usa por ejemplo, sin embargo usado solo, le falta mucha potencia para una aplicación J2EE, pero su papel como WebServer es de lo mejor ! ...

[Dr. Megavolt]

A mi personalmente me gusto Forte, jdeveloper de la suite oracle 10g es bueno pero me parece aveces muy sesgado (ademas de carisimo!!, tu desarrollas gratis pero para vender...)...Tomcat es arriesgado de manejar, el proyecto jakarta avanza con una pereza increible, en ese caso si optaria por el webserver de oracle...

[will_23]

A mi no me parece que Tomcat sea arriesgado de manejar....

El soporte es buenisimo.. y el proyecto jakarta tiene de todo...
Hay que saber como utilizarlo....

y por sobre todo hay que saber sobre lo que uno esta hablando.....

[Dr. Megavolt]

A mi no me parece que Tomcat sea arriesgado de manejar....

El soporte es buenisimo.. y el proyecto jakarta tiene de todo...
Hay que saber como utilizarlo....

y por sobre todo hay que saber sobre lo que uno esta hablando.....

me parece que usted no respeta una opinion, me demuestra soberbia y una mente cerrada a opiniones distintas a las suyas, probablemente usted sepa mucho mas que yo al respecto, no lo dudo, pero deberia respetar mas las impresiones de los demas.... he trabajado tomcat desde hace mucho tiempo y conozco el proyecto catalina desde practicamente sus inicios, y aun asi mantengo la opinion que di hace unos minutos... le invito a montar una base oracle10g con application clusters y un servicio web soportado por tomcat.... pero claro... ud invento J2EE y probablemente ya lo hizo... disculpe mi atrevimiento.

[Grissom.]

Hay depende la arquitectura que se use para los clusters, si se tiene un cluster de Application Servers y deja un solo cluster de Tomcat se le viene abajo, porque hay cuello de botella en el WebServer, toca implementar cluster de WebServer también, y tomcat lo permite: http://www.onjava.com/pub/a/onjava/2002/07/17/tomcluster.html?page=1

En el momento que usted hizo el cluster de Applications Servers depronto dejo cuello de botella con un solo Tomcat y le empezo a fallar, se compro el WebServer de Oracle y le funcionó porque soporta más usuarios, pero también llegará a su punto límite, solo que soporta más que Tomcat.

Tomcat no es mala solución, como dije anteriormente, está tan bien implementado que WebPhere esta basado su WebServer en tomcat, le agregaron soporte para más clientes.

A uno le queda el camello de pensar: ¿me hago un cluster de webserver cuándo tenga más de 200 usuarios?, ó me compro un WebServer como Oracle??? ... dura decisión, en un proyecto hace tiempo la decisión fue el cluster de tomcat y fue bien, el cluster de application server fue con JBoss en aquel momento.

[Dr. Megavolt]

No habia pensado en eso, para serte honesto cuando empezo a presentar problemas la configuracion tenia una deadline muy cercana y pense en implementar todo el paquete que ofrecia el distribuidor, Oracle mas todo..... para un proximo proyecto voy a tener en cuenta tu sugerencia.

Otra cosa.. has trabajado websphere con voice xml (esa es la solucion de ibm ?, o estoy confundido?)

[Grissom.]

Solo he usado el application server, no he usado paquetes de software, API's de ellos (IBM) ... aunque hay que agradecer a IBM porque le ha metido un billete bien duro a Java, por ejemplo Eclipse en gran parte existe gracias a ellos ;) ...

[lemolina]

Muy buen foro, excelente idea, Raul.

Como afirman ser expertos en el tema, me gustaría compartir opiniones respecto al tema que me apasiona con relación al desarrollo J2EE y que creo hizo falta en las combinaciones de herramientas gratuitas: la fase de pruebas.

Toda aplicación realizada con seriedad debe tener un buen proceso de pruebas funcionales y de aceptación, así que qué recomiendan los expertos? Yo he utilizado varias suites, pero son pagadas. Ej: QACenter. He escuchado buenos comentarios de JUnit y JMeter... quién las ha utilizado a fondo?

[will_23]

me parece que usted no respeta una opinion, me demuestra soberbia y una mente cerrada a opiniones distintas a las suyas, probablemente usted sepa mucho mas que yo al respecto, no lo dudo, pero deberia respetar mas las impresiones de los demas.... he trabajado tomcat desde hace mucho tiempo y conozco el proyecto catalina desde practicamente sus inicios, y aun asi mantengo la opinion que di hace unos minutos... le invito a montar una base oracle10g con application clusters y un servicio web soportado por tomcat.... pero claro... ud invento J2EE y probablemente ya lo hizo... disculpe mi atrevimiento.

perdon???

quien es el de la mente cerrada???

el que se las sabe todas????

el de la soberbia????

yo se que Oracle es excelente y que en su campo na hay quien le gane... pero no indica que no pueda haber otros proyectos que sean buenos y puedan implementarse....

[lemolina]

me parece que usted no respeta una opinion, me demuestra soberbia y una mente cerrada a opiniones distintas a las suyas, probablemente usted sepa mucho mas que yo al respecto, no lo dudo, pero deberia respetar mas las impresiones de los demas....

offtopic
Megavolt, no se estrese... Ese ha sido el eterno problema en LANeros.

Cada persona jura y come mocos en que tiene la razón en lo que expresa. Y hacerlos cambiar de parecer es una cruzada muy dificil de llevar a cabo.

Pero bueno, el que sabe, sabe... Y el que no sabe, pelea.

[will_23]

offtopic
Megavolt, no se estrese... Ese ha sido el eterno problema en LANeros.

Cada persona jura y come mocos en que tiene la razón en lo que expresa. Y hacerlos cambiar de parecer es una cruzada muy dificil de llevar a cabo.

Pero bueno, el que sabe, sabe... Y el que no sabe, pelea.

SI estoy de acuerdo...

el que sabe, sabe... Y el que no sabe, pelea.

[Grissom.]

Lucho saludos,

Respondiendo a tu inquietud, cuando se habla de pruebas ese cuento es a diferentes niveles, los más importantes:

1. Ejecución de código, algo así como probar casos de uso: JUnit es excelente.

2. Pruebas de WebServer / Application Server, es cuando quieres probar como le va a tu aplicación con 500, 1000 usuarios por ejemplo, además quieres ver detalles como tiempos de respuestas de la operación total, transferencia de datos, etc ... JMeter es muy bueno.

Finalmente hay un plugin de Eclipse bien interesante, que mide cantidad de instancias de las clases, memoria usada, etc ... algo así como el Optimized de Borland JBuilder, se llama Eclipse Profiler.

offtopic

Pilas, no se pongan a pelear hombre, nadie tiene la última palabra aquí, se trata de aportar y compartir, corregir para aprender ... sugerir mejores opciones, experiencias etc ... me extraña que pierdan objetividad, es antiprofesional eso. Demosle la altura de un foro de expertos.

[Dr. Megavolt]

SI estoy de acuerdo...

el que sabe, sabe... Y el que no sabe, pelea.

Disculpandome por el offtopic y haciendo caso a las recomendaciones de bajar el tono, le cuento hombre, que si ud retrocede en los mensajes, fue usted el que dijo que yo no sabia... si yo me considero un profesional, y pretendo ganarme la vida con esto no puedo aceptar de buena gana su opinion... igualmente yo no fui grosero ni agresivo con lo que opine.... le pido en buenos terminos que reconsidere su opinion acerca de que "no se", hombre, no se si ud trabaje con esto.. pero yo si... y es peligroso profesionalmente que ud me juzgue tan rapido en un teman tan delicado... igual no creo haber demostrado un perfil de ignorancia o algo por el respecto, honestamente ud me ataco porque no estaba de acuerdo con ud y yo lo ataque de vuelta... por los mismos motivos... igualmente dejemos esto a un lado y charlemos mejor de el tema en cuestion...

[Dr. Megavolt]

Que opinan de struts para desarrollo web, mas especificamente manejo de sistemas de informacion tipo web service?

[lemolina]

En las últimas 2 empresas donde he trabajado se han hecho precisamente estudios de rendimiento para comparar el desarrollo con los frameworks Thinlets y Struts... y en ambas ha sido ganador Struts, teniendo en cuenta que la implementación es flexible y robusta al utilizar el patrón Front Controller para el flujo de páginas y adicional a esto las facilidades siguientes:
- Adecuado despliegue de mensajes de usuario
- Manejo de errores
- Características de internacionalización
- Implementación de validaciones de entradas de usuario tanto del lado del servidor como del lado del cliente(JavaScript)
- Generación de contenido dinámico
- Generación condicional de contenido
- Acceso a beans
- Implementación de patrón composite view

En resumidas cuentas, los sistemas de información empresariales deben tener en estos momentos componentes de flexibilidad y adaptabilidad muy altos... y Struts los garantiza.

[will_23]

bien... estoy de acuerdo... creo que si lo ataque..... pero no era lo que queria decir... tal vez no me supe expresar::::

disculpe...

las cosas fueron empeorando y ademas lemolina se metio de ......

[will_23]

Que opinan de struts para desarrollo web, mas especificamente manejo de sistemas de informacion tipo web service?

Struts???

creo que es muy bueno... aunque es aun mejor con algunos complementos....

Han probado Spring??? y que me dicen de ademas un framework para persistencia?? como Hibernate... este conjunto es excelente, y plantea un buen uso del modelo de 3 capas....

[jindix]

He usado Struts y la verdad es excelente, es un FrameWork que tiene muy bien implementado el patrón MVC y como dice Will_23 con unos cuantos complementos como SSLext, DisplayTag, Tiles entre otros se hacen cosas muy buenas y fáciles de mantener y escalar.

Por cierto he escuchado bastante lo de Spring si hay alguien que haya hecho algo por favor que comente...

[lemolina]

las cosas fueron empeorando y ademas lemolina se metio de ......
A mi modo de ver, si ya era tema superado, no era necesario que escribiera eso, Will.
De todas formas, discúlpeme por cuestionarlo.

[jindix]

Ya que andamos en el ambiente J2EE, para todos tengo una inquietud...

Estoy haciendo un Portal, para ello utilizaré el estándar de Portlets Java JSR 168, mi pregunta es is hay alguna forma de llamar a otras fuentes de información, por ejemplo otra aplicación (precisamente hecha con Struts), hasta ahora lo que he encontrado es lo siguiente:

»Struts soportará Portlets JSR168 en la versión 2.0 (bastante lejana la posibilidad)
»Hay contenedores de Portlets (JBoss Portal, JetSpeed) pero no se integran con Struts, eso si ofrecen puentes que simulan aplicaciones hechas con struts pero es pura apariencia...

Alguien conoce otra posible solución?, ayer un amigo me habló algo de MVCPortlet (Algo como Struts pero soportando JSR168) así que en esas ando, si algo nuevo les cuento...

Suerte!

[jindix]

Oiga ya que pare la vaina de los mensajes...

Supuestamente estamos tratando con gente PROFESIONAL!

¿O no?

[will_23]

He usado Struts y la verdad es excelente, es un FrameWork que tiene muy bien implementado el patrón MVC y como dice Will_23 con unos cuantos complementos como SSLext, DisplayTag, Tiles entre otros se hacen cosas muy buenas y fáciles de mantener y escalar.

Por cierto he escuchado bastante lo de Spring si hay alguien que haya hecho algo por favor que comente...

Actualmente uno de los proyectos que manejo lo estoy trabajando con Spring, aunque la verdad creo que me hace falta mucho por aprender.... pero es muy buena opcion....

Tambien he oido de DisplayTag... tiene mas informacion de eso?? me interesa...
:cool:

[jindix]

Actualmente uno de los proyectos que manejo lo estoy trabajando con Spring, aunque la verdad creo que me hace falta mucho por aprender.... pero es muy buena opcion....

Tambien he oido de DisplayTag... tiene mas informacion de eso?? me interesa...
:cool:
OK.

en esta dirección encuentras la librería y ejemplos, si necesitas ayuda me dices...

http://displaytag.sourceforge.net/

Suerte!

[Dr. Megavolt]

Necesito desarrollar una aplicacion del estilo voicexml para un conmutador inteligente, y todos los frameworks hablan maravillas de ellos mismos, recientemente con los foros me entere de spring y vi que asi como struts y websphere y etc etc... hablan maravillas de ellos mismos (algo obvio...) sin embargo la delicadeza de este tipo de aplicaciones (y me refiero a $$$$$) nos obliga (creo que hablo por todos) a definir con delicadeza la arquitectura a manejar.... teniendo en cuenta que voicexml necesita una velocidad transaccional alta y un manejo multitarea verdadero... que opinan ustedes de cual es la mejor opcion ?

[will_23]

Necesito desarrollar una aplicacion del estilo voicexml para un conmutador inteligente, y todos los frameworks hablan maravillas de ellos mismos, recientemente con los foros me entere de spring y vi que asi como struts y websphere y etc etc... hablan maravillas de ellos mismos (algo obvio...) sin embargo la delicadeza de este tipo de aplicaciones (y me refiero a $$$$$) nos obliga (creo que hablo por todos) a definir con delicadeza la arquitectura a manejar.... teniendo en cuenta que voicexml necesita una velocidad transaccional alta y un manejo multitarea verdadero... que opinan ustedes de cual es la mejor opcion ?

Pues no se a que opciones se refiere?????

pero al menos por lo de la velocidad transaccional y especialmente por el manejo de multitarea spring es una buena opcion... Hay ejemplos veridicos funcionando.... con una gran carga de transacciones

[lemolina]

Necesito desarrollar una aplicacion del estilo voicexml para un conmutador inteligente, y todos los frameworks hablan maravillas de ellos mismos, recientemente con los foros me entere de spring y vi que asi como struts y websphere y etc etc... hablan maravillas de ellos mismos (algo obvio...) sin embargo la delicadeza de este tipo de aplicaciones (y me refiero a $$$$$) nos obliga (creo que hablo por todos) a definir con delicadeza la arquitectura a manejar.... teniendo en cuenta que voicexml necesita una velocidad transaccional alta y un manejo multitarea verdadero... que opinan ustedes de cual es la mejor opcion ?
Mi experiencia ha sido con Struts y pues sinceramente para el tipo de aplicación que necesitas realizar no te lo recomiendo al 100%.

Dentro de los patrones, el Front Controller para una muy elevada transaccionalidad se puede convertir en un cuello de botella que vaya en detrimento de la estabilidad de la aplicación y eso es lo que precisamente quieres evitar. Así que es mejor investigar por otro lado las arquitecturas, patrones o hasta las mismas configuraciones con servidores de aplicaciones que te permitan llenar tus expectativas.

[will_23]

Bueno... pero Struts no es la unica opcion.... no???

existen muchas cosas.... por ejemplo que tal es JSF????

o han escuchado hablar de Tapestry?????

[Grissom.]

Lo han dicho ustedes, para eso de las tres capas con patron Front Controller y un código decente con tags en las JSP, Struts es una buena opción, y tengo años trabajando con él, pero ha llegado la hora de divorciarse, les sugiero ir pensando en JavaServer Faces, más comúmente conocido JSF, es el que actualmente uso.

Ventajas:

1. Facilidad para creación de las pantallas ! gestión de nuevos controles, datos tabulares de una mejor manera que como en Struts se hace.

2. Hay algo importante que Struts tuvo la idea de hacerlo, se llama Struts Layouts, JSF funciona similar pero 100 veces más fácil ! ... esto hace más fácil la vida de acomodar los componentes gráficos sin entrar en detalles HTML ....

3. El Controller de JSF es más simple ! ... no hay que crear un Form y Action por cada módulo, o pantalla, ahora se asocia a un Bean de Java "común y silvestre" donde un método retorna un String con el nombre del forward y ya ! ... lo demás es código limpio. Los datos de la pantalla son propiedades del mismo Bean (también pueden usar una delegación, osea una instancia dentro del Bean para guardar los datos, puede ser un TO (Transfer Object) para mandar al servicio posteriormente, llamese EJB, BEAN, WebService.

4. La razón más poderosa de todas: Es de Sun, especificación echa por ellos, y por lo tanto será estándar en las siguiente versión de J2EE. Como dato curioso: esta especificación Faces fue echa por el mismo autor de Struts.

Tiene muchas ventajas más, traten de leer sobre este framework, el los proyectos actuales estoy usando JSF, Struts está pasando a la historia, así de dramatico es el asunto.

Desventajas

1. No soporta tiles, toca hacerle una "maraña" para que funcione, IBM, Exadel entre otros han dado soluciones alternativas, pero no lo soporta directamente la especificación. Sin embargo no es tanta alerta: es versión 1.1 aún, y están en camino versiones con mejoras, quizas tengan tiles para la próxima (Composite View).

2. Algunas cosillas necesitan de crear implementaciones propias para solucionar cosas, ejemplo las validaciones no tienen referencias a los labels, entonces los mensajes de error no traen el nombre del campo con el error implicitamente. Yo lo solucioné implementando un MessageListener simplecito.

APARTE: Respondiendo a la mano de Frameworks que han nombrado, les digo que es de cuidado lo que se decida usar, no sé ustedes, pero la responsabilidad de una decisión tecnologica es grandicima, allá los que solo leen el Java Developer Journal y se enteras de las cosas, pero no les toca cargar con la cruz de escojer una mala plataforma. Para uno ir más seguro es bueno siempre mirar el respaldo de lo que está detrás de estas cosas: Jakarta es buen respaldo, Sun, el grupo JBoss, Hibernate ... entonces, Struts en su momento era la mejor decisión, a lo mejor las demás tenían buenas intensiones pero Struts era algo serio, de igual forma hay muchas implementaciones de JDO, pero Hibernate es excelente ..... mejor dicho, la idea que les quiero vender es, no agarren lo primero que vean por hay que dice hacer algo, tomen experiencias vividas de colegas en otros proyectos, miren sus foros de soporte, quién está detrás, la planeación a largo plazo o si tiene cara de algo pasajero.

[Grissom.]

Necesito desarrollar una aplicacion del estilo voicexml para un conmutador inteligente, y todos los frameworks hablan maravillas de ellos mismos, recientemente con los foros me entere de spring y vi que asi como struts y websphere y etc etc... hablan maravillas de ellos mismos (algo obvio...) sin embargo la delicadeza de este tipo de aplicaciones (y me refiero a $$$$$) nos obliga (creo que hablo por todos) a definir con delicadeza la arquitectura a manejar.... teniendo en cuenta que voicexml necesita una velocidad transaccional alta y un manejo multitarea verdadero... que opinan ustedes de cual es la mejor opcion ?

Has mirado que tan atada está la solución Voice XML a los productos de IBM??? ... si funciona con estándares de J2EE y esas cosas?? ....

Serías tan amable, y yo que estoy un poco ignorante del asunto, nos hablas un poco más de VoiceXML, que soluciona esta API, Framework ... o que tipo de solución es mejor dicho. (Prometo no montar competencia, no quitar la exclusividad je je).

[will_23]

Pues en realidad no se mucho de JSF... pero he visto que tiene buen soporte y existen tutoriales completos de como hacer aplicaciones con JSF,Spring e Hibernate.....

Aunque esos inconvenientes de los que habla El_Rulas me hacen pensar que le hace falta un poco de desarrollo.....

[lemolina]

no agarren lo primero que vean por hay que dice hacer algo, tomen experiencias vividas de colegas en otros proyectos, miren sus foros de soporte, quién está detrás, la planeación a largo plazo o si tiene cara de algo pasajeroExcelente mensaje, Raul. Precisamente creo que ese es el objetivo máximo de este foro que has abierto y que parece un buen punto de partida para empezar diálogos con respecto a nuestras experiencias y lo que recomendamos.
Adelante!

[Dr. Megavolt]

Claro... bueno lo mas interesante de esta tecnologia se aplica actualmente en el campo de los clasicos PBX, la idea es sencilla... 0 operadores humanos y lineas abiertas segun compres... y no es "oprima 1 para..." la idea del voice xml es manejar una gama de diccionarios e inteligencia de nuestro operador virtual, tal que te permita tener con el una charla al telefono "Buenas tardes, me comunicas por favor con fernando fernandez"->"Con mucho gusto señor, de parte de quien ?" -->"de Jaime Jaimes" --> ya mismo se lo comunico", y en ese instante te manda a su extension... quien habra sido esa persona tan amable que me atendio en el telefono pensaria Jaime Jaimes, sin saber que lo atendio nada mas y nada menos que una maquina cargada con un diccionario que podia hasta hablarle de comida thai si quisiera, tenemos el perfecto Bot y con voz femenina de paisa (a lo OLA), Lo pesado es que ademas de plataforma operativa necesita una tarjeta de sonido especial (se mostraba logico... pero hay que hacer la aclaracion..), por el lado de J2EE por supuesto que se soporta y los servers que tienen mas experiencia en esto (o por lo menos fama) son websphere de ibm y el de oracle, se que ademas de jsps tambien soporta asps y cfms.... aqui hay un vinculo que trata particularmente j2ee y voicexml, las ventajas de estar juntos, http://weblogs.java.net/blog/richunger/archive/2005/05/j2ee_architectu.html
http://www.voicexmlforum.org/

No habia creado otro tema al respecto porque depronto me pasaba con lo que me paso con un tema que cree y que creo va a morir sin ser contestado hhehehe, les dejo la curiosidad del otro tema
http://www.laneros.com/showthread.php?t=37180

[Grissom.]

Mr. Megavolt, je je ... es que es normal, los temas especializados son los menos atendidos a veces, pero vaya y vea foros donde preguntan pendejadas, ó temas ambiguos como: ¿Cuál es el más ....? ¿Cuál es el mejor ....? ... dónde cualquiera puede meter la cuchareta, están tetiados de posts. Temas avanzados y especializados como el de ese foro que creaste (que por cierto, no lo había visto, quizas porque bajó rápido y casí nunca miro páginas posteriores), son temas que requieren gente que sepa de verdad del tema, aquí no se puede decir "Yo creo", "Yo pienso", "Pude que sea ..." ... entonces pailas, su tema es muy avanzado y no da lugar a escribir payasadas. Por ejemplo: yo no sé de ese tema tan importante.

[Dr. Megavolt]

Mr. Megavolt, je je ... es que es normal, los temas especializados son los menos atendidos a veces, pero vaya y vea foros donde preguntan pendejadas, ó temas ambiguos como: ¿Cuál es el más ....? ¿Cuál es el mejor ....? ... dónde cualquiera puede meter la cuchareta, están tetiados de posts. Temas avanzados y especializados como el de ese foro que creaste (que por cierto, no lo había visto, quizas porque bajó rápido y casí nunca miro páginas posteriores), son temas que requieren gente que sepa de verdad del tema, aquí no se puede decir "Yo creo", "Yo pienso", "Pude que sea ..." ... entonces pailas, su tema es muy avanzado y no da lugar a escribir payasadas. Por ejemplo: yo no sé de ese tema tan importante.

Si aveces es dificil llevar a cabo este tipo de discusiones, espero que esta discusion de J2EE prospere satisfactoriamente :), Y hablando de eso... una pregunta puntual.... Aplicaciones Java Script tipo AJAX (Asynchronous Java Script and XML), (porque J2EE tambien da un espacio para los scripters), su desarrollo es excelente y la funcionalidad genial... pero solo soporta exploradores nuevos.... no veo como validar el uso de la tecnologia si por ejemplo en una aplicacion tipo portal no todos mis usuarios van a poder verla.... en que momento se le puede exigir al usuario que se actualice para que vea los contenidos de un lugar que en principio puede parecerle poco atractivo.

[Grissom.]

Que características estás usando de AJAX? .... hay características como el "Autocomplete" que tiene Google que ya es un estándar Javascript y hay browsers como Opera que no lo soportan sino hasta la versión 8.0.

Sin embargo, para propósitos de aplicaciones Web yo te recomiendo Firefox 1.0 e Internet Explorer, concentrado en estos dos browsers abarcas mercado Linux, Windows y MacOS. Y además soportan características avanzadas de Scripts.

[will_23]

Ese es el problema eterno... no todos los browser se comportan igual...

El Firefox es el mejor...... pero igual hay que hacer que todo funcione en explorer, por ser el mas utilizado....

[Dr. Megavolt]

Hablando del tema, conocen un debugger decente para javascript en iexplorer... sufro creando scripts tipo ajax corriendolos genial en firefox con su debugger mientras ando rezando para que cuadren en el explorer...

[will_23]

Creo que es muy dificil de encontrar... al menos uno por el que no cobren..........

Es una dificil tarea... pero si encuentra se lo recomiendo;;;::::::: pues me gustaria tambien encontrar uno***

[Grissom.]

De todos modos uno puede programar en Firefox y hacer las depuraciones allá, si uno conoce la especificación Javascript y la usa tal cual, los riesgos de que algo falle es mínimo. Por ejemplo, la especificación dice: "usar el atributo ID para referencias los objetos por getElementById", sin embargo como Internet Explorer permite usar el mismo atributo NAME como ID mucha gente comete el error de hacer:

<input type="text" name="NombreCampo" value="Algún valor"/>

Lo correcto y estándar es:

<input type="text" name="NombreCampo" id="NombreCampo" value="Algún valor"/>

Haciendo lo correcto: getElementById nos funciona en todo lado.

De cosas como esta, muchos programadores no nos percatamos, y despues maldecimos por la compatibilidad, pero sucede que no estamos leyendo la biblia de la religión JavaScript, y aún así pretendemos llegar al cielo.

Mr Megavolt, interesante que uses AJAX ! ... esto te reducira el trafico de datos hasta en un 50%, una aplicación importanticima que veo en esa tecnología (y que el grupo Google la entendió de inmediato) es que uno puede transportar estrictamente el contenido de datos, y ahorrarse mandar la página completa en cada response, llamese mensaje de error, operación exitosa, etc ...

[Whidney]

Disculpen me intrometo, solo queria felicitarlos por este foro, en verdad en este tipo de foros es donde una realmente aprende y se da cuenta cuan atrazado esta, y como dijo El_Rulas, si muchos no partcipamos no es que no nos interese, sino que todabia no programamos a ese nivel.

[will_23]

Vean!!!!!!

encontre una pagina que explica mas o menos como debe ser el manejo de Hibernate por medio de Spring.... creo que dice todo lo necesario::::::::::

http://www-106.ibm.com/developerworks/java/library/j-hibern/#N103BC

[Dr. Megavolt]

Vean!!!!!!

encontre una pagina que explica mas o menos como debe ser el manejo de Hibernate por medio de Spring.... creo que dice todo lo necesario::::::::::

http://www-106.ibm.com/developerworks/java/library/j-hibern/#N103BC
Nice link =)

[VictorV]

A los tesos de java les tengo una consulta.

Soy desarrollador de soluciones en .Net, pero los proyectos de .net en mi empresa finalizan aproximadamente en 1 mes y allí entro a un nuevo proyecto que se va a realizar en java, no se muy bien de que se trata el mismo, pero, si se que es orientado a la web, entonces necesito de ustedes que sabes las siguientes recomendaciones:

1. IDE recomendado
2. Mejores Practicas
3. Recursos

Todo lo anterior orientado a nivel empresarial.


Saludos,

Víctor Manuel Velásquez C.
Microsoft Certified Professional
Instructor .NET 3 Estrellas
Analista de Desarrollo PSL - Productora de software S.A
Medellin, Colombia Latin America

[Grissom.]

Viejo esto es J2EE, vayase a un foro llamado "foro oficial de java", los temas para los que inician en Java se tratan alla.

Suerte.

PD: Sin embargo puedes mirar el primer post de este foro, hay tendras unas sugerencias a un nivel más avanzado.

[lemolina]

Estos son un par de artículos muy interesantes que me encontré en el portal de "Java en Castellano"

Master J2EE Paso 1 (http://www.programacion.com/java/articulo/jap_j2eemaster_1/)

Master J2EE Paso 2 (http://www.programacion.com/java/articulo/jap_j2eemaster_2/)

En total son 12 pasos... para que los tengan en cuenta.

Precisamente me gustó mucho la parte donde tratan el postulado de Ben Galbraith, denominado el 'Principio de Incertidumbre del Marco de Trabajo Java': "Tan pronto como decides utilizar un marco de trabajo, sale una nueva versión de otro marco de trabajo, así una y otra vez".

Interesante.

[Grissom.]

Buen dato Lucho, - reading now - ...

Hablando de información, hay un libro excelente, que no se arrepentirán de comprar, ó bien, conseguir el PDF. Se llama "Expert One-on-One J2EE Design and Development" de la serie Wrox, eso es para leerselo de PA' A PE' !

[mouffetard]

Felicitaciones por este foro. No había vuelto a Laneros desde hace rato (y aunque va a sonar muy chocante lo que voy a decir) porque me perecía que los temas de programación eran demasiado coquitos. Ahora se están tomando en serio el nombre del foro "Programación y Diseño de Software". Excelente.

Mis dos centavos:

Después de varias experiencias en proyectos grandes, medianos y pequeños, mi opinión es que Struts complica demasiado la vida para las aplicaciones empresariales que necesitamos en el país. Ahora he logrado que los desarrolladores utilicen un framework basado en MVC *MUY* simple y resultan construyendo más y mejor código.

Los mismo aplica para los frameworks de persistencia: Evitese complicaciones. En ambientes empresariales el 60% de la lógica del negocio existe hoy y está en StoredProcedures. Reutilícelos implementando DAOs sencillos y evítese la molestia de las herramientas ORM (Hibernate, TopLink, Entity EJB, etc).

Después de un buen diseño, las pruebas son el aspecto más crítico para que una aplicación empresarial sea exitosa. Las pruebas se pueden dividir en tres: Pruebas funcionales, pruebas integración y pruebas de estrés. Para mi, como arquitecto, las pruebas más críticas que indican el éxito del sistema son las dos últimas: qué tan bien se integra el sistema al entorno empresarial y qué tan bien soporta la carga el sistema y logra escalar.

[Grissom.]

No creo del todo mouffetard:

1. ¿Cómo haces para el controller? ó ¿qué patrón aplicas para esa parte?
2. Por lo menos usarás alguna API de taglibs, digamos JSTL ... ó te vas de scriplets limpio? for, while, if ventiao?
3. La idea de los store procedures para procesos críticos: consecutivos y vainas por el estilo, pero ¿casarse de una con la base de datos? ...
4. Las tres pruebas son indispensables, igual de valiosas en una aplicación enterprise, que tal si aguanta 5 millones de usuarios concurrentes y no funciona un carajo :( (Claro que el rol de arquitecto encuentra más atractiva las dos últimas, es su función, el aspecto no funcional).

[HRC-unintended]

Para los que ya están usando AJAX, una preguntica: están usando algún framework que simplifique la tarea de escribir los JS, lo que llaman el "AJAX engine", o están haciendo todo "from scratch"? Qué opciones opensource hay y cuál recomiendan?

[will_23]

Felicitaciones por este foro. No había vuelto a Laneros desde hace rato (y aunque va a sonar muy chocante lo que voy a decir) porque me perecía que los temas de programación eran demasiado coquitos. Ahora se están tomando en serio el nombre del foro "Programación y Diseño de Software". Excelente.

Mis dos centavos:

Después de varias experiencias en proyectos grandes, medianos y pequeños, mi opinión es que Struts complica demasiado la vida para las aplicaciones empresariales que necesitamos en el país. Ahora he logrado que los desarrolladores utilicen un framework basado en MVC *MUY* simple y resultan construyendo más y mejor código.

Los mismo aplica para los frameworks de persistencia: Evitese complicaciones. En ambientes empresariales el 60% de la lógica del negocio existe hoy y está en StoredProcedures. Reutilícelos implementando DAOs sencillos y evítese la molestia de las herramientas ORM (Hibernate, TopLink, Entity EJB, etc).

Después de un buen diseño, las pruebas son el aspecto más crítico para que una aplicación empresarial sea exitosa. Las pruebas se pueden dividir en tres: Pruebas funcionales, pruebas integración y pruebas de estrés. Para mi, como arquitecto, las pruebas más críticas que indican el éxito del sistema son las dos últimas: qué tan bien se integra el sistema al entorno empresarial y qué tan bien soporta la carga el sistema y logra escalar.

Creo que estoy en parte de acuerdo con lo que dice El_Rulas... Aunque estoy de acuerdo en que Struts es un poco complicado... pero por lo menos por el lado de la persistencia no estoy de acuerdo... Al utilizar Spring con Hibernate esto no llega nunca a ser una molestia, cuando se aprende a manejar se hacen cosas muy buenas y rapido.. teniendo codigo reutilizable y muy modular... ademas con la ventaja que si quiero puedo hacer una migracion de motor de bases de datos practicamente sin inconvenientes.

Yo se que es cierto que ya hay muchas cosas hechas y que funcionan... y lo hacen sin este tipo de cosas... pero eso no implica que no se puedan mejorar.. o cambiar el rumbo de estas... Aunque en algunas ocasiones estoy de acuerdo con que lo que esta funcionando no se debe tocar... no es en el 100% de los casos... Muchas veces las cosas deben re-hacerse para tener un mejor desempeño... etc. y creo que es una practica que se deberia usar mas amenudo en algunos casos donde no se toca lo que se tiene por muchos factores.. pero puede ser bueno...

Y por ultimo una pregunta...
cuando dices
Ahora he logrado que los desarrolladores utilicen un framework basado en MVC *MUY* simple y resultan construyendo más y mejor código.
Cual es ese framework *MUY* simple?? y porque es *MUY*?????
Gracias.....

[Grissom.]

....

Yo se que es cierto que ya hay muchas cosas hechas y que funcionan... y lo hacen sin este tipo de cosas... pero eso no implica que no se puedan mejorar.. o cambiar el rumbo de estas... Aunque en algunas ocasiones estoy de acuerdo con que lo que esta funcionando no se debe tocar... no es en el 100% de los casos... Muchas veces las cosas deben re-hacerse para tener un mejor desempeño... etc. y creo que es una practica que se deberia usar mas amenudo en algunos casos donde no se toca lo que se tiene por muchos factores.. pero puede ser bueno...

Y por ultimo una pregunta...
cuando dices

Cual es ese framework *MUY* simple?? y porque es *MUY*?????
Gracias.....

Cobol también funciona, y los archivos planos, y no por eso voy a dejar de usar bases de datos ... es decir, las cosas evolucionan y mejoran, en principio no existía Struts, ni Faces, tampoco Hibernate ni JDO, pero la arquitectura moderna exije estas cosas para mejorar el desarrollo.

Si Struts le pareció engorroso a alguno, tiene Faces como alternativa, más fácil no se puede en el momento ;) . Personalmente siempre me parecio engorroso crear un ActionForm bien sea implementando el Bean, ó usando el DynaForm (Que felicidad cuando salió posteriormente). Faces maneja este cuento mucho mejor ! ... me gusta más el "populate" de Faces.

Repondiendo la inquietud de AJAX, recuerden que esto es una arquitectura, no una API, ni tecnología, sin embargo la implementación es bastante fácil. Además es fácil de integrar con Faces ... para las validaciones queda del carajo !.

[mouffetard]

No creo del todo mouffetard:

1. ¿Cómo haces para el controller? ó ¿qué patrón aplicas para esa parte?
2. Por lo menos usarás alguna API de taglibs, digamos JSTL ... ó te vas de scriplets limpio? for, while, if ventiao?
3. La idea de los store procedures para procesos críticos: consecutivos y vainas por el estilo, pero ¿casarse de una con la base de datos? ...
4. Las tres pruebas son indispensables, igual de valiosas en una aplicación enterprise, que tal si aguanta 5 millones de usuarios concurrentes y no funciona un carajo :( (Claro que el rol de arquitecto encuentra más atractiva las dos últimas, es su función, el aspecto no funcional).

1 y 2. Se utiliza el Patrón MVC Model-2, es decir, un servlet que hace las veces controller. No todo el flujo de la aplicación pasa por un solo controller, lo más aproximado es que cada Caso de Uso pasa por un Controller. Además, las Views son JSP que utilizan TAGLIBS, de manera que se trata de reducir al máximo el código dentro de las JSP. Los proyectos empresariales son arriesgados y entre más simple sea lo que se utiliza como plataforma, mejor le irá en el proceso de desarrollo y mantenimiento.

3. La realidad en las empresas grandes es que tienen procedimientos almacenados que ya hacen la mayoría de la lógica, por ejemplo: validación de direcciones, cruces de información, cuadres, operaciones CRUD sobre modelos corporativos, etc. Y sí, las empresas están de hecho, casadas con un proveedor de base de datos. Aquí no hay mucha que decir, a menos de que se desarrolle software genérico, que es otro paseo.

4. Desde nuestro punto de vista de "Desarrollo y Diseño de Software" es más importante que el software funcione bien a que funcione como el cliente lo especificó funcionalmente. Desde el punto de vista de elicitación de requisitos y aproximaciones metodológicas, es más importante que el software funcione como el cliente lo especificó, es más, que funcione como el cliente lo soñó.

[mouffetard]

Y por ultimo una pregunta...
cuando dices

Cual es ese framework *MUY* simple?? y porque es *MUY*?????
Gracias.....

Jeje...*MUY* simple se refiere a que son a lo más, 3 clases que el desarrollador debe dominar, nada más: La dos clases abstractas que equivalen a las Actions de Struts y un componente de seguridad que le permite realizar la autorización sobre las opciones de la aplicación.

[Grissom.]

mouffetard, a continuación voy a comentar unas cosas de tus puntos, recordando que el foro es un asunto para mejorar, aprender y compartir información, puede que me equivoque pero iremos con argumentos firmes y puntuales llegando a el punto de que es mejor y cuando. Listo? ... dice así:

1 y 2. Se utiliza el Patrón MVC Model-2, es decir, un servlet que hace las veces controller. No todo el flujo de la aplicación pasa por un solo controller, lo más aproximado es que cada Caso de Uso pasa por un Controller. Además, las Views son JSP que utilizan TAGLIBS, de manera que se trata de reducir al máximo el código dentro de las JSP. Los proyectos empresariales son arriesgados y entre más simple sea lo que se utiliza como plataforma, mejor le irá en el proceso de desarrollo y mantenimiento.


Aquí hay trabajo que ya te hace el framework,

1. Los request llegan en formato String todo y sin validar, te toca la galleta de la conversión, así sea Client / Server side, como la pongas.

2. Te toca rellenar los Beans para transferencia de datos tu mismo, esto ya lo hacen estos frameworks.

¿Cómo manejas este camello?


3. La realidad en las empresas grandes es que tienen procedimientos almacenados que ya hacen la mayoría de la lógica, por ejemplo: validación de direcciones, cruces de información, cuadres, operaciones CRUD sobre modelos corporativos, etc. Y sí, las empresas están de hecho, casadas con un proveedor de base de datos. Aquí no hay mucha que decir, a menos de que se desarrolle software genérico, que es otro paseo.


La realidad de las empresas grandes, estimado, es que muchas tienen aún sistemas legacy, y lógica en los motores de base de datos, cosa que no indica que sea lo correcto o lo mejor, sino es lo que tienen hace mucho tiempo y cuesta mucho migrarse a sistemas modernos y mejores como J2EE que recomiendan fuertemente usar 3 capas, las razones sobran decirlas conociendo que estamos entre expertos.

Tu aplicación hace algo mal si es una aplicacion moderna y recien implementada, y es que es una mala practica empujar la logica de negocio en las bases de datos, eso un arquitecto J2EE lo descarta de salida, para eso se hicieron los EJB. Usted se está volando la capa de negocio y la está mesclando con la de persistencia: 2 en 1?? su aplicación tiene dos capas, no sé ni para que crea DAO's ??? que está abstrayendo?? tiene la aplicación en su base de datos :( ... Además eso de validar los datos como direcciones en la base de datos FATAL ! ... eso va más arriba.

Que la mayoría de empresas usen metodologías antiguas, no significa que las aplicaciones modernas deban ser programadas de tal forma, esto ha evolucionado, y cuando se pueda se debe implementar las nuevas arquitecturas, salvo que hayas tomado un sistema que esta funcionando perfectamente así y te quieras facilitar la vida reusando esos Store procedures ya creados es diferente, si la comenzaste de cero y metiste la lógica de negocio así, grave ! ...

Como lo dije, su sistema funciona y COBOL con archivos planos y una sola capa también :D.


4. Desde nuestro punto de vista de "Desarrollo y Diseño de Software" es más importante que el software funcione bien a que funcione como el cliente lo especificó funcionalmente. Desde el punto de vista de elicitación de requisitos y aproximaciones metodológicas, es más importante que el software funcione como el cliente lo especificó, es más, que funcione como el cliente lo soñó.
[/QUOTE]

Esto es correcto, el cliente a veces no sabe ni lo que quiere, solo le interesa solucionar un problema, y ese es nuestro trabajo.

[will_23]

Ahhh, veo... No parece tan descabellado como suena al principio...
aunque como siempre hay que ver la situacion para poder decir que seria lo mejor....

Trato de no tomar una inclinacion radical... aunque actualmente trabajo con Struts, Spring e Hibernate que me han dado muchas ventajas y tambien tiempo para dedicarle a cosas diferentes a la programacion que son muy importantes y muy poco tenido en cuenta en muchos de los desarrollos que se hacen en las empresas nacionales e incluso de america latina.

En fin... dependiendo del problema se debe atacar de forma distinta... y en este punto es muy bueno no estar casado con nada.. y que se tengan varias opciones.

[will_23]

Insisto.........

No hay porque tomar decisiones tan radicales!!!!!!!!!!!!!

y no lo digo porque si...................
lo digo basado en el libro de Wrox - Expert One-on-One - J2EE Design and Development

Que aun no he terminado de leer, pero que habla sobre temas como la discusion que estamos teniendo ...

Y hay cosas (NO todo)que no suenan tan descabelladas de lo que dice *mouffetard* , se podria llegar a un hibrido.........

[mouffetard]

mouffetard, a continuación voy a comentar unas cosas de tus puntos, recordando que el foro es un asunto para mejorar, aprender y compartir información, puede que me equivoque pero iremos con argumentos firmes y puntuales llegando a el punto de que es mejor y cuando. Listo? ... dice así:


Excelente discusión, así si le da ganas a uno de echar carreta e invertir un poco de su tiempo en compartir opiniones. Con el ánimo de fundamentar mi posición, los siguientes son mis argumentos.

Parte I
¿Cómo manejas este camello?

Si señor, a mano y es no es tan fuerte el camello. Vean, pongámonos prácticos con las cosas. Supóngase que se necesita, dentro de una aplicación desarrollada con lo último en guarachas (Struts/Spring/Hibernate) una pantalla que lista las personas con algún criterio, con la cédula y nombres completos. El usuario quiere que le de clic a la cédula y me lleve a la pantalla de los detalles, y ahí si me muestre toda la información completa de la persona. Yo creo que más de uno ya ha hecho esta pantalla unas 10 veces.

Solución 1:
Utilice hibernate (con HQL, QBE, o cualquier otra cosa) y recupere la List(a) de personas que satisfagan ese criterio. Lleve la información (si es bien pilo con un DTO) hasta el controller y a su vez llévelo a su View, por ejemplo a través de un Form (Struts). Luego utilice un tag del tablib - LOGIC de Struts para recorrer la colección y haga una marañita en JavaScript para modificar una hidden que contenga la cédula de la persona a la cual el usuario le haga clic, y que además, haga el submit de la form.

Solución 2:
Vaya a la base de datoa y ejecuta el StoreProcedure que le devuelve un cursos con la lista de cédulas y nombres de personas. Si es bien inteligente utilice un DAO para abstraer esta lógica de acceso a recursos empresariales y no haga la brutalidad de implementar esta lógica en el cotroller. Genere un HashMap, en donde la key es la Cédula y el element sea el nombre (String, String). Transfiera este DTO hasta la View, que es una JSP que utiliza una TAGLIB para recorrer la colección.

Contras Solución 1: Se trae, si su aplicación utiliza lazzy loading (el más optimizacido de los casos) se trae todo los objetos hidratados (como lo dice Martín Fowler), lo que sin lugar a duda no es óptimo en procesamiento y memoria en la base de datos y en memoria en servidor de aplicaciones. En el peor de los casos (lo más común, desafortunadamente), se trae TODO el grafo de objetos alcanzable desde Persona
Ventajas Solución 1: Mucho más rápido de desarrollar. Mucho más portable.
Contras Solución 2: Requiere creación de DAO y mantenimiento de SQL. Puede requerir dos gramos más de neuronas de parte del desarrollador.
Ventajas Solución 2: Mucho más eficiente en memoria y procesamiento en BD, mucho más eficiente en memoria en el AppServer.

En mi experiencia, ese ahorro obtenido por la solución 2, permite que la aplicación soporte un mayor carga. Es muy diferente diseñar una aplicación para 10 usuarios concurrentes que para 100 usuarios concurrentes.

Parte II: Todo en su debida medida.
Los EJB son una solución excelente para la distribución de componentes cuando se necesita escalar en la capa media. Hay que aclarar, primero que todo, que el patrón de arquitectura “División por Capas” es una división lógica que puede realizarse físicamente en diferentes niveles. “No hay que se más papista que el papa”.

Existen muchos ejemplos en los que la capa intermedia se sitúa tanto en el nivel 2 como en el nivel 1. La ventaja de situar la capa intermedia en el nivel 1 es, sin lugar a dudas, la estabilidad, desempeño, confiabilidad y capacidades comprobadas y practicadas a diario de los motores de base de datos líderes del mercado (exceptuando SQL Server, por supuesto) son superiores a los de los servidores de aplicaciones (WebLogic, WebSphere, Oracle Application Server - no sé nada de JBOSS).

Si una compañía de Software está desarrollando un producto genérico, tiene todo el sentido del mundo utilizar la capa intermedia para la lógica del negocio ya que aumenta su portabilidad y por lo tanto la posibilidad de obtener mayor número de clientes.

Por el contrario, si una compañía tiene todo su back-end con un proveedor, tiene todo el sentido utilizar el nivel 2 como capa intermedia cuando detecte que el nivel 1 es cuello de botella y no soporta la carga impuesta por el nivel 2. Esto es MUY poco probable. Es mucho más probable que una instancia de Oracle en RAC soporte millones de peticiones a que una Cluster de AppServers soporten millones de peticiones y no lo digo yo sino la madurez de los motores de base de datos.

Absolutamente errado lo de meter que es buena práctica meter SIEMPRE la lógica de negocio en la capa intermedia. Todo depende de lo que se quiera lograr y del objetivo (comercial, funcional, no funcional) del sistema.

Parte III:
Un arquitecto no excluye tecnologías de su caja de herramientas. Selecciona aquellas que son más adecuadas y las mezcla para cumplir con los requisitos no funcionales y para ofrecer una arquitectura armoniosa y equilibrada. No creo que un arquitecto J2EE experimentado elimine de tajo el uso de SPs como parte de su solución. Creo que los utilizaría si está disponibles y utilizaría EJB cuando requiera ofrecer escalabilidad o cuando requiera integración con otro tipo de sistemas.

Parte IV:
Las metodologías de elicitación de requisitos no tienen una relación directa con la forma en que se diseñan y desarrollan los sistemas. Es innegable que influyen, pero no son el factor definitivo. El factor definitivo es el arquitecto de la aplicación.

Las metodologías modernas están enfocadas en el desarrollo “Ágil”, que puede ser logrado con COBOL o con programación orientada por Aspectos.

[Dr. Megavolt]

Yo tengo una opinion muy basica y demasiado empirica.......... los sp`s dividen la aplicacion en capas y bla bla carreta carreta funcionan muy bacano.... que si se usan asi ahora... pues lo que he visto es que es la mejor alternativa, por seguridad, por conceptos cliente servidor, por integridad, etc... que es dificil de pronto decirle a la manada de empresas que usan siigo y timax y toda esa vaina, que hay nuevas alternativas... pues si... es complicado... sobre todo en empresas de gama media,.... en conclusion, mi centavo como dicen por ahi.... saben que me saco de quisio haciendo una aplicacion con SP`S basada en la base de datos ???..... cuando tenia que sacar las actualizaciones....... dios mio........ mejor dicho... si la va a hacer con SPS espere hacerla perfecta.. porque va a tener lios en la migrada ida y vuelta........tener un framework como un gorro vacio es chevere y facilita la programacion pero hay que tener mucho cuidado con lo que se programa.

[Grissom.]

Excelente discusión, así si le da ganas a uno de echar carreta e invertir un poco de su tiempo en compartir opiniones. Con el ánimo de fundamentar mi posición, los siguientes son mis argumentos.


;)


Parte I


Si señor, a mano y es no es tan fuerte el camello. Vean, pongámonos prácticos con las cosas. Supóngase que se necesita, dentro de una aplicación desarrollada con lo último en guarachas (Struts/Spring/Hibernate) una pantalla que lista las personas con algún criterio, con la cédula y nombres completos. El usuario quiere que le de clic a la cédula y me lleve a la pantalla de los detalles, y ahí si me muestre toda la información completa de la persona. Yo creo que más de uno ya ha hecho esta pantalla unas 10 veces.

Solución 1:
Utilice hibernate (con HQL, QBE, o cualquier otra cosa) y recupere la List(a) de personas que satisfagan ese criterio. Lleve la información (si es bien pilo con un DTO) hasta el controller y a su vez llévelo a su View, por ejemplo a través de un Form (Struts). Luego utilice un tag del tablib - LOGIC de Struts para recorrer la colección y haga una marañita en JavaScript para modificar una hidden que contenga la cédula de la persona a la cual el usuario le haga clic, y que además, haga el submit de la form.

Solución 2:
Vaya a la base de datoa y ejecuta el StoreProcedure que le devuelve un cursos con la lista de cédulas y nombres de personas. Si es bien inteligente utilice un DAO para abstraer esta lógica de acceso a recursos empresariales y no haga la brutalidad de implementar esta lógica en el cotroller. Genere un HashMap, en donde la key es la Cédula y el element sea el nombre (String, String). Transfiera este DTO hasta la View, que es una JSP que utiliza una TAGLIB para recorrer la colección.

Contras Solución 1: Se trae, si su aplicación utiliza lazzy loading (el más optimizacido de los casos) se trae todo los objetos hidratados (como lo dice Martín Fowler), lo que sin lugar a duda no es óptimo en procesamiento y memoria en la base de datos y en memoria en servidor de aplicaciones. En el peor de los casos (lo más común, desafortunadamente), se trae TODO el grafo de objetos alcanzable desde Persona
Ventajas Solución 1: Mucho más rápido de desarrollar. Mucho más portable.
Contras Solución 2: Requiere creación de DAO y mantenimiento de SQL. Puede requerir dos gramos más de neuronas de parte del desarrollador.
Ventajas Solución 2: Mucho más eficiente en memoria y procesamiento en BD, mucho más eficiente en memoria en el AppServer.

En mi experiencia, ese ahorro obtenido por la solución 2, permite que la aplicación soporte un mayor carga. Es muy diferente diseñar una aplicación para 10 usuarios concurrentes que para 100 usuarios concurrentes.


Estás diciendo que la complejidad de hacer validaciones y conversiones a pulso no es tan complicado? ... además de manejar el flujo del programa cuando bota el error de validación? rellenar el objeto Transfer para mandarlo al DAO para que guarde ... fechas, numeros, decimales, rangos ... yo prefiero declararlo en un taglib diciendo "required=true" y con las validaciones de tipos de datos implicita según el tipo de dato en el bean. No hay como la programación declarativa ! ahora, no se trata de la capacidad de hacer una de las dos, ambas pueden tener la misma complejidad de aprendizaje, pero cual es más fácil de mantener?.

Lo de traerse todo el grafo es un asunto de usar bien las vainas, tampoco se trata de replicar el modelo de la base de datos en un modelo de objetos hibernate como muchos creen, haciendo cuanta relación existe y mapeando todo. Si se requiere un punto crítico para una consulta puede perfectamente usarse un SQL JDBC ó store procedure directamente, usar hibernate para las consultas simples, no usarlo para todo como es lógico.


Parte II: Todo en su debida medida.
Los EJB son una solución excelente para la distribución de componentes cuando se necesita escalar en la capa media. Hay que aclarar, primero que todo, que el patrón de arquitectura “División por Capas” es una división lógica que puede realizarse físicamente en diferentes niveles. “No hay que se más papista que el papa”.

Existen muchos ejemplos en los que la capa intermedia se sitúa tanto en el nivel 2 como en el nivel 1. La ventaja de situar la capa intermedia en el nivel 1 es, sin lugar a dudas, la estabilidad, desempeño, confiabilidad y capacidades comprobadas y practicadas a diario de los motores de base de datos líderes del mercado (exceptuando SQL Server, por supuesto) son superiores a los de los servidores de aplicaciones (WebLogic, WebSphere, Oracle Application Server - no sé nada de JBOSS).

Si una compañía de Software está desarrollando un producto genérico, tiene todo el sentido del mundo utilizar la capa intermedia para la lógica del negocio ya que aumenta su portabilidad y por lo tanto la posibilidad de obtener mayor número de clientes.

Por el contrario, si una compañía tiene todo su back-end con un proveedor, tiene todo el sentido utilizar el nivel 2 como capa intermedia cuando detecte que el nivel 1 es cuello de botella y no soporta la carga impuesta por el nivel 2. Esto es MUY poco probable. Es mucho más probable que una instancia de Oracle en RAC soporte millones de peticiones a que una Cluster de AppServers soporten millones de peticiones y no lo digo yo sino la madurez de los motores de base de datos.

Absolutamente errado lo de meter que es buena práctica meter SIEMPRE la lógica de negocio en la capa intermedia. Todo depende de lo que se quiera lograr y del objetivo (comercial, funcional, no funcional) del sistema.



Que pena estimado pero se comió el cuento completo del proveedor de su base de datos y me lo amarraron bien bueno. JAMÁS he visto la capa media siendo cuello de botella, con load balancing eso nunca pasará, es físicamente imposible (asumiendo que tenemos canal de red infinito, y maquinas en crecimiento horizontal claro está). Hay aplicaciones corriendo con miles de usuarios al día y con EJB manejando business logic, en la base de datos la única lógica es algoritmos bien críticos y generación de consecutivos. Eso si usando un buen motor, Oracle corriendo en Unix, pero exclusivamente para almacenar, consultar y algunos store procedures.

Pero si alguien se quiere amarrar, está bien, es indudable que la producción se aumenta, es viable también, pero no es porque no se pueda de la otra forma, mejor dicho ese argumento del cuello de botella estuvo apresurado para mi experiencia vivida.


Parte III:
Un arquitecto no excluye tecnologías de su caja de herramientas. Selecciona aquellas que son más adecuadas y las mezcla para cumplir con los requisitos no funcionales y para ofrecer una arquitectura armoniosa y equilibrada. No creo que un arquitecto J2EE experimentado elimine de tajo el uso de SPs como parte de su solución. Creo que los utilizaría si está disponibles y utilizaría EJB cuando requiera ofrecer escalabilidad o cuando requiera integración con otro tipo de sistemas.


Estimado, aquí hay una mala interpretación, y yo primero que usted dije esta parte "No creo que un arquitecto J2EE experimentado elimine de tajo el uso de SPs como parte de su solución.", un post antes de que usted contestara este le anoté que dadas unas circunstancias esto era viable. Lo que no me parecia es manejar la lógica de negocio de toda la aplicación en este lugar, entendiendo que estos son aplicaciones escalables de gran concurrencia el uso de EJB se hace indispensable para manejar la logica en capa intermedia. Los puntos que ha dicho del arquitecto J2EE son válidos y no veo donde se ha dicho lo contrario, así que quedé azul hay.


Parte IV:
Las metodologías de elicitación de requisitos no tienen una relación directa con la forma en que se diseñan y desarrollan los sistemas. Es innegable que influyen, pero no son el factor definitivo. El factor definitivo es el arquitecto de la aplicación.

Las metodologías modernas están enfocadas en el desarrollo “Ágil”, que puede ser logrado con COBOL o con programación orientada por Aspectos.


Amén.



=============================


Pero te hago una pregunta, basandote en tu punto aquí expuesto, te pongo este escenario: Tienes una aplicación nueva, no hay nada echo, ni base de datos y ninguna línea de código, la aplicación requiere muchos usuarios concurrentes, digamos 100 concurrentes reales.

1. Usas logica de negocio en los store procedures.
2. Usas EJB y la base de datos para almacenamiento y algunos procedimientos críticos en store procedures.
3. Aplicas otra solución ¿Cuál?

[will_23]

;)


Lo de traerse todo el grafo es un asunto de usar bien las vainas, tampoco se trata de replicar el modelo de la base de datos en un modelo de objetos hibernate como muchos creen, haciendo cuanta relación existe y mapeando todo. Si se requiere un punto crítico para una consulta puede perfectamente usarse un SQL JDBC ó store procedure directamente, usar hibernate para las consultas simples, no usarlo para todo como es lógico.



100% de acuedo con esto..............................
Es solo cuestion de saber manejar las cosas.... NO hay porque traerse toda la base de datos... a menos que sea totalmente necesario...(que no lo creo)

Con un buen uso de los frameworks y unas buenas consultas se pueden llegar a unos resultados excelentes... y lo digo por experiencia propia... He visto trabajando estas herramientas MUY bien..... y he implementado un par de soluciones a partir de ellas, y aunque no han tenido una carga de transacciones muy grande se han comportado de la mejor manera con el uso de los recursos::::::::::.

[mouffetard]

;)

Pero te hago una pregunta, basandote en tu punto aquí expuesto, te pongo este escenario: Tienes una aplicación nueva, no hay nada echo, ni base de datos y ninguna línea de código, la aplicación requiere muchos usuarios concurrentes, digamos 100 concurrentes reales.

1. Usas logica de negocio en los store procedures.
2. Usas EJB y la base de datos para almacenamiento y algunos procedimientos críticos en store procedures.
3. Aplicas otra solución ¿Cuál?

Una acotación al alcance del escenario: Es una aplicación EMPRESARIAL y no un paquete genérico que será vendido, es decir, un desarrollo a la medida para una empresa establecida y que requiere alto desempeño y gran escalabilidad.

1, 2 y 3: Uso Stateless EJB cuando detecte que el procesamiento que se tenga que hacer en la capa intermedia *DEBE* poder escalar (horizontal o verticalmente). NO USO CMP EJB, tal vez lo pensaré con EJB 3.0 . Utilizo StoredProcedures cuando requiera procesamiento fuerte en base de datos, de lo contrario armo mi Capa de servicios de persistencia, me explico:

Si el modelo de datos es pequeño (menos de 20 tablas), utilizo una capa de persitencia a la medida (DAO + DTO), externalizando los SQLs.
Si el modelo de datos es grande (20 o más tablas), utilizo una capa de persistencia implementada con un framework ORM para las cosas que considere necesarias, es decir, cuando la complejidad de armar archivos de mapeo, etc (obviemos cosas como MiddleGen, por ahora), exceda el beneficio obtenido en disminución de tiempo de desarrollo.

La capa der servicios de persistencia me permite conectar y desconectar el framework de persistencia según se requiere en el futuro.

3. SIEMPRE pienso en el uso de un CACHE en la capa intermedia para información estática o con poca probabilidad de actualización. En las arquitecturas por capas es fundamental el uso de CACHE y es un elemento que hay que tener en cuenta cuando se piensa en una concurrencia de 100 usuarios reales. Aquí si veo un punto fuerte para Hibernate, sin embargo no sé si el cache que este utiliza soporta Clustering. Me inclino a pensar que no. Las soluciones de cache que he utilizado han sido basadas en Singletons (muy malos para Clustering) y otros caches distribuidos, por ejemplo Java Object Cache de Oracle. Estoy interesado en Coherence, de Tangosol, pero aun no lo he probado.

Un complemento metodológico básico:
SIEMPRE trato, en la medida de lo posible, elaborar un documento de arquitectura completo utilizando la aproximación 4+1, en el que se explican los casos de uso de interés para arquitectura y a partir del cual los desarrolladores pueden iniciar la implementación de los casos de uso del sistema. Esto sirve como plantilla, lineamiento y referencia para posteriores auditorías y mantenimiento.

[will_23]

3. SIEMPRE pienso en el uso de un CACHE en la capa intermedia para información estática o con poca probabilidad de actualización. En las arquitecturas por capas es fundamental el uso de CACHE y es un elemento que hay que tener en cuenta cuando se piensa en una concurrencia de 100 usuarios reales. Aquí si veo un punto fuerte para Hibernate, sin embargo no sé si el cache que este utiliza soporta Clustering. Me inclino a pensar que no. Las soluciones de cache que he utilizado han sido basadas en Singletons (muy malos para Clustering) y otros caches distribuidos, por ejemplo Java Object Cache de Oracle. Estoy interesado en Coherence, de Tangosol, pero aun no lo he probado.


Yo se que no hago mas que defender Spring... y lo voy a seguir haciendo en esta ocasion.....
Este framework ayuda a hibernate con lo del clustering.....

No se realmente si hibernate es capaz de soportarlo por si mismo, porque no lo he necesitado...Pero si se que Spring colabora con este aspecto y permite crear buenas implementaciones para estos casos......

y otra cosa....
He visto funcionar Tangosol...... es bueno......... lo utilizan en mi universidad para un proyecto de mallas... y ademas tiene licencias educativas......

[Grissom.]

Perfecto ! ... ¿cuál sería la única razón para poner la lógica de negocio de la base de datos?

* Sistemas existentes.
* Que tengas un personal que solo conoce PSQL (ó el lenguaje que sea de la BD) y la aplicación se necesite para YA y mandarla hacia la WEB, una emergencia mejor dicho.

En lo posible, la lógica de negocio en aplicaciones enterprise J2EE debería estár en EJB, salvo que sea MUY NECESARIO colocarla en un store procedure de la base de datos.

Comparto también la molestia por los CMP y BMP, jamás me ha gustado usarlos.

Les cuento que el cache distribuido también me quedo corto, tengo teorias y se también de la existencia de Tangosol, pero no he hecho algo real de cache distribuido, para mi - a lo mejor me equivoque - es una utopia, creo que el proceso es tan complejo en la medida que el clustering y load balancing crece se volvería más lento refrescar los caches que pegarle a la base de datos.

Interesante que alguno nos diera un concepto más real de cache distribuido.

[will_23]

Pues realmente.... del tema.... se muy poco....

pero depronto en esta pagina http://ungrid.unal.edu.co/
pueden encontrar informacion... es la pagina del proyecto de mallas del que escribi antes...

El profesor que lo lidera sabe mucho de esto... y si no hay informacion disponible, tal vez se le pueda hacer una consulta

[mouffetard]

Perfecto ! ... ¿cuál sería la única razón para poner la lógica de negocio de la base de datos?

* Sistemas existentes.
* Que tengas un personal que solo conoce PSQL (ó el lenguaje que sea de la BD) y la aplicación se necesite para YA y mandarla hacia la WEB, una emergencia mejor dicho.


Te faltó una fundamental: Si el proceso de negocio o lógica de negocio necesita muchos datos que están en la base de datos, es más eficiente hacerlo como un StoredProcedure.

Y yo agrego uno más: Si la lógica del negocio hace parte del core del negocio y necesita ser reutilizada por otras plataformas (C/S, .NET, etc) sería conveniente, desde el punto de vista de arquitectura general y no de la aplicación, implementar dicha regla como una SP.

Y otra razón que creo que es la que aterriza toda la teoría: Muchas empresas ya tienen *MUCHA* logica codificada en SPs y es una restricción *fundamental* reutilizar este patromonio intelectual.

[mouffetard]

Pues realmente.... del tema.... se muy poco....

pero depronto en esta pagina http://ungrid.unal.edu.co/
pueden encontrar informacion... es la pagina del proyecto de mallas del que escribi antes...

El profesor que lo lidera sabe mucho de esto... y si no hay informacion disponible, tal vez se le pueda hacer una consulta

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.

[Grissom.]

mouffetard, ¿ya probó algo de tangosol? no es gratuito, pero no es tan costoso, parece ser de lo mejorcito para atacar ese problema de cache distribuido..

¿Qué Application Server estan usando para el cluster, y ¿cómo se ha portado? ...

[mouffetard]

mouffetard, ¿ya probó algo de tangosol? no es gratuito, pero no es tan costoso, parece ser de lo mejorcito para atacar ese problema de cache distribuido..

¿Qué Application Server estan usando para el cluster, y ¿cómo se ha portado? ...

No he probado Coherence, he leido mucho, pero todavía no se ha alcanzado la masa crítica necesaria para que se invierta en el producto de Tangosol.

Estamos utilizando Oracle Application Server 10g. Este AppServr tiene diferentes configuraciones de Clustering, en estos momentos estamos experimentando con algo conocido como Islands, en las que, para un solo contenedor se crean dos o más JMVs y de esa manera se balancea la carga. Ahí es donde fallan todas las soluciones basadas en Singletons, los heap de las JVM, obviamente, no son compartidos.

[Grissom.]

¿Qué han usado para gestión de ayudas online? que no sea el manual HTML estático ó el nene documentico de Word.

[mouffetard]

¿Qué han usado para gestión de ayudas online? que no sea el manual HTML estático ó el nene documentico de Word.
Nada nuevo, el viejo y conocido HTML.

[mouffetard]

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.

[Grissom.]

La experiencia que tengo con los grupos de trabajo J2EE que he visto, es satisfactoria en general, en ese aspecto la mayoría acá en Bogotá desde hace un año, vienen usando buenos habitos de arquitectura, patrones, fachadas, buena abstracción.

Tiempo atras vi muchos desastres, código de conexión JDBC sin usar pool de conexiones en las propías JSP's, ejecución de sentencias JDBC sin gestionar las Exception's de modo que quedaban abiertas si alguna excepción era arrojada, cosas así: las típicas que uno encuentra muchas veces en las auditorias de aplicaciones. Algunos entendieron las ventajas de los patrones inmediatamente, otros se negaron a entender, les parecia innecesario tantos pasos y se apoyaban en que las cosas estaban funcionando bien hasta el momento, pero al final la lógica ganó menos mal :D ...

Aún no faltan este tipo de compañias que desarrollan sin arquitectura, generalmente donde los grupos de desarrollo son pequeños e inexpertos, ó tienen un desarrollador haciendo las veces de DBA, diseñador UML (si lo usan), desarrollo, pruebas, soporte y hasta ventas.

Hablando de los grupos donde yo participo, por fortuna para mi, somos gente bien especializada, el 90% sabe lo que es un Business Delegate, un Front Controller, Facade, Abstract Factory, etc ... los patrones más comunmente usados, por lo tanto el lenguaje arquitectural manejado es bastante rico.

Medellín debe ya tener buen personal preparado en cuanto a arquitectura J2EE se refiere, Intergrupo le viene metiendo el diente desde hace dos años a J2EE y ellos eran Microsoft 100% antes.

[lemolina]

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é.

[Grissom.]

Qué me recomiendan para este dilema en el que ando, la situación más o menos es esta: Sucede que hay unos XML que tienen la ayuda de una aplicación bien definida, algo así:


<topic id="0001">
<title>Título de la vaina</title>
<keywords>pendejada, ******************</keywords>
<content>Esta carreta es así y asao, y hace estas huevonadas</content>
<moreinfo>
<link ref="0005">
</moreinfo>
</topic>

<topic id="0002">

....



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

1. Puedo usar XSLT con parámetros para ejecutar las consultas de los topicos y además generar el código HTML.
2. Mandar eso a una base de datos y ejecutar las consultas allá con un precioso indice en los campos de búsqueda, y escribir el código HTML de ayuda con un objeto rellenado con toda la información resultado de la consulta en la base de datos. Algo así:

class Topic implements Serializable {
String id;
String content;
List links;

// ... getter setters add y toda la joda ...
}


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.

[will_23]

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.

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...

[will_23]

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.

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....

[lemolina]

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.

[mouffetard]

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é.

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.

[mouffetard]

¿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.

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?

http://www.laneros.com/attachment.php?attachmentid=20078&stc=1

[Grissom.]

Mmm los algoritmos para este caso pueden ir en cualquiera de los dos lugares, entran a jugar los siguientes puntos:

1. No es lógica de negocio, juzgandolo por el propósito puede ir en un SP facilmente, o dejarlo en software.

2. Tampoco es un proceso super crítico que necesite un tiempo de respuesta ni el berraco.

3. Necesito desacoplarlo de la base de datos, en un caso de migración siempre se terminarían escribiendo algunos SP, pero entre menos mejor porque recortamos el tiempo de la fase de pruebas funcionales.

Hasta el momento teniendo en cuenta esos puntos, veo que la mejor opción es dejarlo en código Java.

----------------

Redondeando la solución, viendo tu solución que se ve tentadora:

1. Proceso offline:
* Genera el contenido en HTML con registros asociados en la base de datos conteniendo los keywords y la tabla de referencias URL - ID Topic ...

2. Módulo Java para ejecutar estas consultas: Por keyword, por búsqueda usando algoritmo de calificación de relevancia.

3. Pantallas web para ejecutar las consultas y creación de contextos en los diferentes módulos que invocan su ayuda.

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?.

[mouffetard]

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?.

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.

[mouffetard]

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?

[Grissom.]

Service oriented-architecture, me parece una arquitectura bien solida, ya hay implementaciones en producción y funcionando bien, por medio de webservice, también la he usado para desarrollo de servicios internos, resulto bastante viable porque el grupo de desarrollo es grande y esto hace el trabajo bien modular además. La aplicación con webservices se conecta con una de .NET por cierto :D ...

Con respecto a SOA-J2EE creo que los EJB's deben hacer algo para facilitar este trabajo, esperemos que la versión J2EE 1.5 tenga esto de una manera más natural.

[mouffetard]

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.

[Grissom.]

En mi opinión a BEA, Webphere, iPlanet (ó Sun One creo que se llama ahora) les queda más berraco estar al día con la tecnología, quizas por lo que tienen que garantizar perfecto funcionamiento, responderle a un cliente que se acaba de bajar con unos buenos miles de dolares, de verdad era impresionante q

[Grissom.]

En mi opinión a BEA, Webphere, iPlanet (ó Sun One creo que se llama ahora) les queda más berraco estar al día con la tecnología, quizas por lo que tienen que garantizar perfecto funcionamiento, altísima concurrencia, responderle a un cliente que se acaba de bajar con unos buenos miles de dolares, de verdad era impresionante que BEA soportara J2EE 1.4 cuando ninguno de los demás (Excepto JBoss) lo soportaran aún.

Tocando otros temas, hablando de realidades que cualquiera de ustedes conozcan en Colombia: sabemos que en los grupos de desarrollo grandes buscan respaldo, soporte local y el software libre es descartado muchas veces por esta razón, y se pagan sumas bien grandes, por ejemplo todos sabemos que IBM no es nada baratongo, ... sin embargo desde el punto de vista de ustedes, dadas las experiencias vividas, que sale menos costoso en realidad?

Por ejemplo, en una compañía compramos el directory server de Novell, teniendo un problema tecnico hemos llamado a Argentina, dada la complejidad del asunto, allá estaba la central de soporte ó algo así, de donde lo único que han hecho para resolver el problema es mandar copias del manual PDF que tienen ellos. Llamamos nuevamente diciendo que requeriamos alguien que se encargara del problema, y no que nos mandaran copias del manual, nos respondieron que eso era otro tipo de soporte diferente y que tenía otro costo. Mejor dicho, la compra del producto no incluía el soporte total.

Dado el escenario anterior, una de las soluciones era pagar el otro tipo de soporte, que consideré absurdo, ó adoptar una solución más economica por las cuales hasta incluye soporte "online" en otro país (digase USA), ó hasta adquirir una solución libre y dejar el asunto al "cacharreo" que sale mucho más barato aún.

Continuando con soluciones en busca de respaldo local, en mi opinión he visto errores:

* JBuilder, en lugar de Eclipse que es libre y no me cuesta un peso ! si quiero asistentes para generar EJB, deployments descriptors, Struts, JSF etc .. me compro MyEclipse que cuesta 40 dolares un año de uso.

* Webphere, en lugar de BEA, siendo este último mucho más fácil de configurar y superior en sus algoritmos de cluster y load balancing.

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

[will_23]

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

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???

[mouffetard]

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.

[mouffetard]

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?

[jindix]

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...

[swoko]

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...

[Grissom.]

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...

Lo que pasa es que no toda aplicación debe tener EJBs, esto depende de las necesidades de la aplicación. Esta es una de las decisiones más importantes por cierto.

Se deben aplicar los EJBs si la situación realmente lo amerita, hay muchos puntos a tener en cuenta de acuerdo al tipo de aplicación: es distribuida?, tiene una transaccionalidad compleja entre diferentes métodos / componentes de negocio?, alta concurrencia? necesitará clustering? load balancing?. En el libro "Wrox Expert One-on-One J2EE Design and Development" dice unos buenos puntos a tener en cuenta para tomar una buena decisión. Algo importante dicho por el señor mouffetard, en lo cual estoy de acuerdo, es que la aplicación debe hacerse lo más simple posible, si tienes el papayazo de no usar EJB's pues haganlo. Sin embargo tenganlo bien en cuenta "lo más simple posible", si su aplicación es distribuida y además tiene una serie de requerimientos no funcionales que los EJB's solucionan, sería más complejo no usarlos :) ...


(http://www.wrox.com/WileyCDA/WroxTitle/productCd-0764543857.html)

[mouffetard]

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.

[jindix]

... Lo importante es que los diseñadores y desarrolladores del sistema tengan suficiente experiencia para lograr sistemas eficientes y robustos...

Esto es cierto, pero como hariamos aquellos que iniciamos con cierto framework o plataforma, cuales creen ustedes deberían ser los proyectos que sirvan como "entrenamiento", aunque la verdad ningun proyecto es sencillo aunque asi lo parezca

Gracias.

[Grissom.]

jindix, algo recomendable es fundamentarse bien. La mayoría de las veces los grupos de desarrollos tienden a tomar ejemplos de código e implementar en su aplicación inmediatamente, sin reparar en conceptualizarse con el framework, leer los detalles fundamentales desde la conversión de tipos de datos Java - Base de datos, y resto de cosas que le parecen "chichis" pero que son trasendentales. Ejecutan las cosas a la empirica, prueba / error hasta que funciona por una vez en la maquina local. Esto hace mucho daño al desarrollo de la aplicación, una buena solución es tener un buen director de desarrollo, experimentado y capaz de guiar bien al grupo mientras se fortalece en dichas plataformas. Si el director de desarrollo experimentado no es posible tenerlo por falta de presupuesto, o cualquier otro motivo no queda más que dar el mejor esfuerzo e ir pagando las consecuencias de la novatada.

De mi parte tengo una pregunta, es un problema común presentado en el desarrollo, y estoy casí seguro que más de uno lo ha enfrentado de algún modo. Se trata de la paginación de los resultados de una consulta, es decir, consultas de muchos elementos son generalmente fraccionadas por un factor (generalmente 10). ¿Qué soluciones han encontrado para esto?, en el mercado colombiano he visto varias:

1. Consultan todos los elementos, guardan el manojo de datos en sesión y los van accesando entre diferentes request. Esta solución es logicamente desastroza si de verdad hay una cantidad de elementos consultados. Además, teniendo en cuenta que la aplicación puede tener alta concurrencia, imaginense una buena cantidad de usuarios, cada uno con este lista guardado en su sesión http://imagenes.laneros.com/smilies/smiley%20-%20depressed.gif ...

2. Algunos le dejaron la tarea al DAO, aplicando la sintaxis de acuerdo a cada motor de base de datos, para reducir el tamaño de la consulta y comenzarse desde / hasta donde se requiera.

3. La más sensata hasta el momento, de las que he visto, quizas hay mejores. Hibernate permite manejar este problema, además super importante para los que necesitamos abstracción con el motor de base de datos.

A continuación les pongo diagrama estático UML - más conocido como diagrama de clases - ¿qué solución podría ser mejor? ...

Como anoto en el diagrama, estoy inconforme con manchar la interface de negocio con información no funcional para llevar el conteo de la página, o quizas estoy envolatado con los conceptos y la información de la paginación es funcional? ... cualquier opinión bienvenida y agradecida de antemano. Gracias.

PD:
Adjunto 1: Imagen formato PNG del diagrama.
Adjunto 2: Para los que tengan argouml es un proyecto (la versión usada de Argo es 0.18.1).

[mouffetard]

En una empresa de desarrollo, yo haría proyectos internos que necesite, por ejemplo, recursos humanos, contabilidad, la misma gerencia etc..., con nuevos frameworks que se quieran explorar. Con esta alternativa tendríamos dos ventas: el riesgo económico es mucho más bajo pues lo asume la misma empresa y no un cliente, la experiencia se desarrolla en forma real, no con ejemplos que muchas veces no cubren muchos casos de uso importantes.

[mouffetard]

2. Algunos le dejaro