J2EE (Solo expertos)

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í:

mouffetard dijo:
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.
Haz clic para expandir...

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.
Haz clic para expandir...

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ñó.
Haz clic para expandir...
[/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.
 
  • Me gusta
Reacciones: 2 personas
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.
 
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.........
 
Mis argumentos - largo

El_Rulas dijo:
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í:
Haz clic para expandir...

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?
Haz clic para expandir...

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.
 
  • Me gusta
Reacciones: 2 personas
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.
 
mouffetard dijo:
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.
Haz clic para expandir...

;)

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.
Haz clic para expandir...

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.
Haz clic para expandir...

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.
Haz clic para expandir...

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.
Haz clic para expandir...

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?
 
El_Rulas dijo:
;)


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.
Haz clic para expandir...

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::::::::::.
 
El_Rulas dijo:
;)

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?
Haz clic para expandir...

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.
 
mouffetard dijo:
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.
Haz clic para expandir...

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......
 
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.
 
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
 
El_Rulas dijo:
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.
Haz clic para expandir...

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.
 
will_23 dijo:
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
Haz clic para expandir...

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.
 
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? ...
 
El_Rulas dijo:
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? ...
Haz clic para expandir...

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.
 
¿Qué han usado para gestión de ayudas online? que no sea el manual HTML estático ó el nene documentico de Word.
 
Patrones de Diseño

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

Los últimos mensajes

Los últimos temas

Arriba Pie
Atrás