development - playframework java
.NET-vs EJB (4)
¿Cuál es la tecnología comparable de EJB (Enterprise Java Beans) en .net?
La definición de términos es importante
Al hacer comparaciones, la definición de términos es importante. EJB es un modelo de componente. Define las capacidades de persistencia, transacción, comunicación remota, activación y seguridad (y quizás otras) para los componentes que operan dentro del contenedor.
Puede ver tecnologías similares en .NET, si eso es lo que busca: las capacidades técnicas del modelo de componentes.
Por otro lado, algunas personas usan "EJB" como un término para referirse a J2EE (o Java EE?). En cuyo caso se refiere no solo a un modelo de componente, sino a un conjunto de tecnologías Java relacionadas generalmente asociadas a las aplicaciones del lado del servidor, incluido un modelo de componente. Esto podría incluso incluir conjuntos de herramientas, que, por supuesto, solo se relacionan tangencialmente con el modelo del componente. Si esa es la comparación, entonces se describe más adecuadamente como "J2EE vs. .NET".
Otras personas podrían estar usando una definición aún más difusa para EJB para incluir elementos como la capacidad de servicios web, comunicaciones REST / XML u otras cosas que están estrictamente fuera de Java EE o EJB. En otras palabras, cuando dicen "comparar EJB con .NET" realmente quieren comparar "Plataformas Java del lado del servidor con .NET del lado del servidor". Este último me parece una comparación mucho más práctica que hacer comparando, digamos, modelos de componentes.
Al hacer las comparaciones, es importante tener claro qué es lo que se está comparando.
EJB - el modelo de componente
En EJB, define un objeto y lo marca como un bean de sesión o un bean de entidad. También está la adición tardía de Message Driven Bean. Tres sabores de componente en EJB. El Session Bean se activa: cómo se inicia y, posiblemente, se "pasiva" en momentos de alta contención de recursos en el servidor / contenedor. La SB también obtiene servicios de seguridad y control remoto.
La idea básica es definir un objeto y luego adjuntarle atributos, ya sea a través del descriptor de implementación o a través de los atributos de código, el análogo para el que se llama annotations en Java.
Lo más parecido a un EJB Session Bean es un objeto .NET. En cualquier aplicación .NET, puede marcar un objeto con atributos de transacción, como un EJB SB. Puede hacerlo remotable, si lo desea, con .NET Remoting y más atributos. Fuera de COM +, no hay tecnología de pasivación en .NET; .NET simplemente ignora la agrupación como una cosa generalmente interesante que hacer con los objetos en memoria, y como resultado, no hay un enfoque para hacer la activación / pasivación en .NET como ocurre con EJB.
barra lateral # 1: eso no es del todo cierto. En .NET, la capacidad de flujo de trabajo proporciona una facilidad para tener actividades de larga duración que pueden ser pasivadas y reactivadas. Sin embargo, Workflow es una metáfora distinta de "objetos del lado del servidor" o "servicios", que es el punto central de la mayoría de las arquitecturas de aplicaciones del lado del servidor que utilizan .NET.
barra lateral n. ° 2: solía ser que los diseñadores de las plataformas del lado del servidor pensaban que todos querían usar la agrupación de objetos para ser más eficientes. Ahora resulta que JVM y .NET CLR son lo suficientemente rápidos para crear objetos, y la memoria es lo suficientemente abundante, que en general, la agrupación de objetos no es de uso práctico. Ya no es interesante para el caso general, aunque todavía ofrece buenos dividendos para objetos caros como las conexiones de bases de datos.
Al igual que con EJB, en .NET puede adjuntar atributos de seguridad a un objeto para permitir que se ejecute o no en función de la identidad del llamante u otra "evidencia".
Los frijoles de la entidad son un animal diferente. Si bien la persistencia y la comunicación remota se pueden combinar, en la mayoría de las guías prácticas, la recomendación es que un bean de entidad no exponga una interfaz remota. En su lugar, la recomendación requiere que un bean de sesión llame a un bean de entidad. Así que consideremos los EB como objetos persistentes.
En .NET hay un montón de alternativas aquí. LINQ-to-SQL ofrece una opción: con ORM y servicios de persistencia. El Entity Framework de ADO.NET es quizás una tecnología más comparable. Por supuesto, todos los demás servicios en .NET (seguridad de transacciones y comunicación remota, etc.) también se pueden aplicar a objetos que usan Entity Framework de ADO.NET o LINQ.
Por otro lado, dependiendo de dónde se encuentre su énfasis en el paraguas de EJB, puede haber mejores comparables. Si utiliza principalmente EJB para el control remoto, y con la llegada de REST, SOAP y otros protocolos ligeros, casi nadie hace esto por lo que puedo decir, entonces una mejor versión comparable en .NET es WCF.
Finalmente, los comparables a EJB MDB son .NET Queued Components.
EJB Remoting
Hay algunos aspectos comunes a todos estos tipos de EJB, como las interfaces remotas. En realidad, la mayoría de los arquitectos recomiendan que no distribuyas tus EJB. En otras palabras, desalientan a las personas a usar el aspecto remoto que se discute tan comúnmente. En su lugar, un servlet debería invocar un EJB que sea local, en lugar de invocar uno en una máquina remota. Esta es la primera ley de Fowler : no distribuyas tus objetos .
Por otro lado, a veces debes hacerlo.
WCF es el marco de comunicaciones dentro de .NET, y es el aspecto en .NET más comparable al control remoto de EJB. Pero no son equivalentes. WCF es un marco de propósito muy general para comunicaciones remotas, compatible con sincronización y asíncrono, protocolos múltiples y transporte extensible y modelo de canal, mientras que el control remoto de EJB es bastante limitado.
¿Comenzando desde EJB el enfoque correcto?
EJB no dice nada (que yo sepa) sobre servicios web, REST, administración o marcos ligeros, o incluso HTML, o herramientas de desarrollador. Comenzar una comparación con "EJB vs blank " restringe artificialmente la discusión un poco. Enmarca la discusión de una manera que puede no ser óptima.
No hay nada en EJB para manejar, por ejemplo, una metáfora de página HTML. Obtienes eso en los servlets o uno de sus primos (portlets, etc.), algunos de los cuales están en J2EE. Pero estrictamente hablando, la salida HTML no está cubierta en EJB.
Ahora, tal vez intentes una de las definiciones más amplias de EJB. Para ese fin, J2EE ahora ha agregado servicios web en la especificación. Pero aún así, no estoy seguro de cuán relevante es considerar la especificación, con la variedad de marcos complementarios basados en Java para servicios web SOAP y REST.
Del mismo modo, si desea considerar las capacidades de UI como portlets, servlets y AJAX y compararlas con los equivalentes de .NET, entonces se ha movido mucho más allá de EJB y J2EE y en Java en el servidor en general.
Vuelve a mi punto anterior: sea claro y preciso en su mente acerca de lo que le interesa examinar o comparar.
Las especificaciones de EJB y J2EE eran ambiciosas: intentar definir los marcos para las aplicaciones del lado del servidor. Pero siempre hubo un lapso de tiempo entre lo que los desarrolladores estaban haciendo, lo que decía la especificación y lo que los proveedores ofrecían. Usted sabe, tal vez hubo un retraso de 1 año entre la finalización de una nueva versión de la especificación J2EE y el lanzamiento de un servidor compatible de IBM.
Debido a esto, terminó siendo algo artificial, después del hecho. La especificación describía cosas que la gente ya estaba haciendo. Cosas como Spring salían y J2EE no decía nada sobre ellas. Durante mucho tiempo, J2EE no tuvo nada que decir sobre REST, servicios web o AJAX. (Incluso ahora, ¿dice algo sobre AJAX? No lo sé.)
A la luz de la distancia entre la teoría de la especificación y la realidad de la práctica real de los desarrolladores, un mejor enfoque podría ser identificar los requisitos de la aplicación y luego comparar la idoneidad de EJB y otras tecnologías relacionadas con las aplicaciones que desea compilar.
En otras palabras, suponga que uno de sus requisitos es que la aplicación se entregue a través del navegador y que tenga la capacidad de respuesta de AJAX. En ese caso, tendrá que considerar jQuery, y eso no está cubierto por J2EE o EJB. Los frameworks AJAX están disponibles en varios productos (tanto Java como .NET). Por ejemplo, Visual Studio usa jQuery para las cosas de ASPNET AJAX. Pero apegarse a las especificaciones de alguna manera se pierde esto.
Línea de fondo
La conclusión es que cualquier aplicación que construya con EJB puede construirse en .NET y viceversa.
Creo que una comparación como "EJB vs .NET" puede interesarse como una discusión académica, pero si desea obtener información práctica sobre qué tecnología usar donde, entonces debe pensar un poco diferente.
Debe identificar y priorizar los requisitos, como la velocidad de desarrollo, el costo de implementación, el mecanismo de implementación, el soporte de herramientas, la plataforma de implementación, el soporte de idioma, el rendimiento, la apariencia de la interfaz de usuario, las opciones de la interfaz de usuario, etc. Luego, compare las opciones con esa lista de prioridades.
Uno podría argumentar fácilmente Spring.NET ...
Spring se está convirtiendo en la norma en el lado de Java, ya sea como complemento de JavaEE / EJB o simplemente reemplazándolo. Muchos de los conceptos en Spring son muy similares a JavaEE / EJB, pero simplemente mejores. Spring.NET es, obviamente, la implementación de .NET.
Más allá de esto, no podría sugerir nada más, ya que no he usado .NET en años ...
WCF en .Net 3.5 es el más similar siempre y cuando no intentes usar CMP. Si bien permite puntos finales de servicio para cosas de tipo SOAP, también permite la comunicación remota binaria.
gran parte de la funcionalidad EJB ya es nativa en .net (es decir, transacción de base de datos) pero existe el espacio de nombres de servicios empresariales que también proporciona mucha funcionalidad.