¿Por qué hay tanta confusión en el mundo de Java con varios servidores como apache, tomcat, jboss, embarcadero, etc. y en .Net World es solo IIS que hace ese trabajo. Me gustaría entender la necesidad y el uso de la misma y no estoy comenzando un java vs. .net.¿Por qué las aplicaciones Java necesitan un servidor de aplicaciones y .Net solo el servidor web IIS?
Existen varias razones.
Un servidor de aplicaciones Java EE es un monitor de transacciones para componentes distribuidos. Proporciona una serie de abstracciones (por ejemplo, nombres, puesta en común, ciclo de vida de los componentes, persistencia, mensajería, etc.) para ayudar a lograr esto.
Muchos de estos servicios son parte del sistema operativo Windows. Java EE necesita la abstracción porque es independiente del sistema operativo.
También se debe decir que la especificación completa de Java EE no es necesaria para el desarrollo de aplicaciones web. JDBC, la parte de Java que trata con bases de datos relacionales, es parte de Java SE propiamente dicha. Java EE agrega servlets, que son escuchas HTTP, y Java Server Pages, que es un lenguaje de marcado para generar servlets. Puede desarrollar aplicaciones web completamente funcionales usando solo estas tecnologías y Java SE. Tomcat y Jetty son dos motores servlet/JSP que pueden sustituir servidores de aplicaciones Java EE completos.
Si toma nota del hecho de que .NET tiene escuchas HTTP integradas en el módulo System.Net, se da cuenta de que es como si .NET tomara una página de Java y doblara la funcionalidad javax.servlet en el marco.
Si agrega Spring y una funcionalidad de mensajería como ActiveMQ o RabbitMQ, puede escribir aplicaciones completas sin tener que recurrir a WebLogic, WebSphere, JBoss o Glassfish. No necesita EJB o la especificación Java EE completa.
ACTUALIZACIÓN:
primavera de arranque ofrece la posibilidad de desarrollar y ejecutar aplicaciones Java con todas las funciones como un archivo JAR ejecutable. No es necesario ningún servidor de aplicaciones Java EE, solo JDK 8 o superior.
Entonces, si .NET tiene que hacerse independiente del sistema operativo, ¿tenemos que ir por la ruta de un servidor de aplicaciones como la abstracción? –
@CodeToGlory, si desea que el código escrito en .NET se ejecute tal cual en una variedad de sistemas operativos o que .NET sea implementado por múltiples proveedores, entonces necesitaría abstracciones equivalentes siempre que se invoquen funciones específicas de plataforma o sistema operativo y un estándar definido para todos los servicios que cumplirían todos los proveedores múltiples. – Yishai
En primer lugar, puede ejecutar el código .NET apagado Apache usando mod_mono, por lo que es no limitado a IIS. También hay varios otros servidores web (se les ocurren a Cassini y a XPS) que también ejecutarán ASP.NET.
Para ejecutar una aplicación web dinámica necesita un servidor web y un servidor de aplicaciones. Algunas veces estos se integran tan bien que parecen ser uno y lo mismo, a veces no.
En lo que respecta a Java, siempre ha sido compatible con más plataformas que .NET y ha sido más abierto, por lo tanto se ha integrado a más servidores web (en la pila de Linux).
Como tanto .NET como IIS son tecnologías que provienen de Microsoft, ASP.NET y los aspectos del servidor de aplicaciones (aspnet_isapi.dll) se incluyeron con IIS y los diferentes instaladores .NET se integran con IIS. Por supuesto, Microsoft solo lo implementó en su sistema operativo y para su servidor web.
Porque Java EE es una especificación, no un producto en sí. Recuerde que Java es mucho más abierto que .NET (en el sentido de la especificación).
Cada servidor de aplicaciones tiene características diferentes, rendimiento diferente, diferentes usuarios/empresas de destino, diferentes etiquetas de precios, ejecuciones en diferentes plataformas, requieren hardware diferente. La diferenciación es la razón por la que existen todos los servidores de aplicaciones, un tamaño no sirve para todos.
Apache es muy similar a IIS, y no tiene mucho que ver con Java.
Los Servidores de aplicaciones en Java proporcionan servicios adicionales que .NET ofrece de varias maneras, con diferentes productos o desde el sistema operativo Windows.
Apache se usa generalmente en implementaciones Java como un proxy para un servidor de aplicaciones detrás de él, y potencialmente sirve contenido estático, o maneja SSL, y preocupaciones similares. Es completamente opcional, aunque hay buenas razones para usarlo.
Tomcat y Jetty son básicamente servidores web java, que proporcionan un marco definido (Servlets, entre otras cosas) para crear sitios web dinámicos con código Java. A menudo son componentes de un servidor de aplicaciones más grande o pueden implementarse solos.
JBoss es un ejemplo de un servidor de aplicaciones (Glassfish y Weblogic son dos otros muy comunes), que proporciona la especificación J2EE completa. La idea detrás de la especificación J2EE es permitir una forma definida de construir un servidor de aplicaciones para que una aplicación pueda cambiarse entre diferentes servidores de aplicaciones de diferentes proveedores que cumplan con la especificación. La especificación trata sobre cómo interactuar con servicios definidos que son útiles para el programa del lado del servidor.
Las opciones de herramientas son una de las ventajas y desventajas de Java, consulte los marcos de desarrollo web Java disponibles, puede evaluarlos interminablemente solo para decidir. en .Net es más o menos MVC. Con los servidores es relativamente simple. La mayoría va a Tomcat si necesitan un servidor web y JBoss si necesitan un servidor de aplicaciones gratuito. Las razones de esto ya se han dicho, J2EE es una especificación.
AHem Ahem ... Formas web. – tster
Una razón es que escribir un servlet es tan fácil como implementar la interfaz javax.servlet.Servlet en una clase concreta. Los contenedores de servlets, entonces, solo necesitan soportar una API bastante simple para llamarse a sí mismos servidores web. Esto hace que establecer un contenedor de servlets sea extremadamente simple debido a este contrato limitado de funcionalidad.
Esto se debe a que Sun y Microsoft tenían objetivos muy diferentes con su software y formas de alcanzar ese objetivo.
El Sun mantra para Java ha estado desde el principio "Escribir una vez, ejecutar en todas partes", y eso ha resultado en mucho esfuerzo para crear _API_ que especifiquen cómo debería ser el entorno para permitir una pieza minimalista de código hacer su trabajo.
La API para "procesar una solicitud web y devolver una respuesta web" se llamó Servlets, y ha sido extremadamente exitosa debido a que llena un vacío y está bien especificada. Todos principales servidores web basados en Java que conozco permiten ejecutar servlets. Una implementación temprana de un servidor web completo habilitado para servlet is only 1500 lines Más tarde esto se amplió para incluir JSP's para proporcionar HTML con el código del lado del servidor (como PHP).
Para que cualquier solución sea verdaderamente escalable, incluidas las soluciones web, significa que, finalmente, la carga es tan alta que una computadora no es lo suficientemente potente como para funcionar por sí misma. Un escalable solución MUST sea capaz de propagarse a través de múltiples ordenadores conscientes unos de otros, y que solo requisito trae un montón de otras cosas a la mesa:
Sun creó entonces de API para todas las funciones que encontraron eran necesarios para que esto funciona, y lo llamó "Java Enterprise Edition" (esos días se utilizó la palabra "empresa" para muchas cosas), y creó un sistema que implementa todas estas API que las personas pueden comprar y usar.
La diferencia entre Microsoft y Sun ahora entra en juego. Aquí, Microsoft simplemente haría público a IIS y diría "use estas API" en los clientes, pero en realidad no quiere que nadie cree otro servidor que proporcione estas API. ¡Porque quieren vender Windows para ejecutarlo!
Sun quería que la gente a usar la lengua en su lugar, por lo que hicieron posible que cualquier persona para implementar la especificación Java EE, pero tuvieron que pasar una serie de pruebas rigorious del Sol (y pagar) que se le permitiera uso la Marca Java EE. Esto ha provocado que haya una gran cantidad de servidores Java EE disponibles, en los que generalmente puede reutilizar la lógica empresarial principal, pero tiene que configurar el servidor Java EE para proporcionar los recursos que la aplicación necesita.
Consulte http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition#Certified_application_servers para conocer el estado actual de los servidores. Tanto el comercial como el de código abierto están disponibles según sus necesidades. Elija el que más le convenga.
Por lo tanto, la razón es que Java EE es un conjunto de API bien definidas que cualquiera puede implementar, y lo han hecho.
Gracias @Thorbjorn, la única queja que tengo es que me tomó mucho tiempo construir un ejemplo simple de Hello World en Java usando eclipse, jboss, jsf en comparación con asp.net, que parecía mucho más sencillo. También tuve que hacer mucha configuración e incluso descargar hormiga antes de poder escribir una línea de código. –
La manera más fácil de comenzar con JEE es Netbeans con GlassFish. http://netbeans.org/downloads/ –
¿Por qué IIS no es un servidor de aplicaciones? –
@CaptainGiraffe ¿por qué tiene que ser así? – cbmeeks