Qu� Java necesita la mayor�a ser la lengua preferida del Web 2.0
Muchos pensar�an que a este punto estoy hablando de una mejor ayuda de AJAX en la base. Mientras que necesitamos una mejor ayuda para AJAX y no estoy hablando de DWR, no pienso que es qu� aflige Java en su b�squeda para ser. En el extremo miraremos dos maneras de las cuales poder superar este problema.
Java est� tomando un golpeo en una mejor adopci�n total contra el PHP simplemente porque es m�s duro fijar en el ambiente del recibimiento de tela. El PHP e incluso el rub� est� disponibles como m�dulo de Apache que sea muy trivial fijar y utilizar. JSP/Servlets por una parte es mucho m�s duros de integrar con Apache.
�Por qu� Apache est� el llave a la adopci�n del Web 2.0?
Apache es el web server m�s popular, sabido para su estabilidad y facilidad de empleo. Es plataforma cruzada. La mayor�a de las compa��as y de los productos del Web 2.0 conf�an en Apache como su web server y por razones correctas.
�Cu�les son los problemas de Java en la integraci�n de Apache?
Complejidad en cortocircuito. El Tomcat es probablemente el JSP m�s popular, envase de Servlet para la mayor�a de las organizaciones. El Tomcat est� libre (que ayuda a su renombre) y convertido bajo organizaci�n de Apache. Habr�a esperado que ambos estos productos fueran integrados firmemente. En realidad es una pesadilla del infierno incluso a comenzar. No dir�a que no hay ninguna documentos. Hay pocos confusos que lleva a m�s preguntas que respuestas. Qu� carecemos es una pauta simple clara para integrar los dos.
Soluciones
Previouly I hab�a descrito una manera mucho m�s simple de integrar el Tomcat 5.5 con Apache 2.x, en apenas 5 pasos.
Sin embargo necesitamos movernos m�s lejos. Necesitamos hacer el envase de Java Servlet tan f�cilmente integratable como el PHP o el rub�. Funcionar con un caso separado del Tomcat puede no ser una soluci�n aceptable a muchos abastecedores del recibimiento de tela. Necesitamos poder funcionar con el Tomcat dentro de Apache s� mismo, utilizamos sus hilos de rosca. En el pasado distante hab�a otro proyecto JServ de Apache que hizo eso. Fue continuado m�s adelante a favor de Tomcat. El Tomcat es de gran alcance pero la mayor�a de los peque�os reveladores no necesitan su gama completa de capacidades. La mayor parte de ser�an felices con un subconjunto m�s peque�o que est� disponible por todas partes, incluso en un recibimiento del d�lar.
Y finalmente Sun y la comunidad de Java necesita acercarse a abastecedores del recibimiento de tela y hacer la lengua ubicua en cada plataforma de recibimiento, grande o peque�a. Apachefriends ha hecho un trabajo admirable con XAMPP para la comunidad de la L�MPARA y ha hecho el Tomcat 5.5 disponible con su instalaci�n simplificada de la L�MPARA. Ahora si solamente podr�amos empaquetar Java con todo el linux y las instalaciones del DEB por abandono
Archivado bajo noticias de t�tulo, software de Java, tecnolog�a, Web, recibimiento de Web, servicios de Web |�
� |
� RSS 2.0 |�
� Trackback este art�culo | �
� Env�e por correo electr�nico este art�culo
Usted puede tambi�n tener gusto de leer |
Agregue a los favoritos de Technorati
26 de septiembre de 2006 en el 5:11
Convenga totalmente. Recuerdo mi primer proyecto de xml/jsp sobre JServ para Onstar. La parte de qu� Java necesita a la OMI es la misma oleada de los reveladores que utilizan el PHP, el rub�, el etc. apuntando el revelador de la empresa no es bastante.
26 de septiembre de 2006 en el 8:59
JServ funcion� en un proceso separado de Apache y utiliz� un conectador de la MOD de apache, apenas como Tomcat hace. �Recuerde el mod_jserv? Realiz� exactamente la misma funci�n que mod_jk, pero mucho m�s limitado. No era ninguna alegr�a al configur tampoco.
La dificultad con el Tomcat de funcionamiento que el IP con Apache es usted no puede funcionar con el c�digo de Java dentro de otro proceso. Usted tiene que comenzar para arriba una VM como su propio proceso y despu�s utilizar el IPC para comunicar entre Apache y el Tomcat. Es ciertamente que algo Sun podr�a tratar con la VM, pero no he o�do cualquier cosa sobre ellos que se mov�an en esa direcci�n.
Adem�s, las compa��as grandes tienden a elegir separar sus funciones del servidor y del web server del app en diversas m�quinas. Que la manera usted puede proteger los servidores de base de datos u otros recursos protegidos contra ser alcanzado y el ser atacado en el web server. Es tan sobre todo tiendas m�s peque�as o los reveladores individiual que se beneficiar�an de combinar el web server y los servidores del app.
26 de septiembre de 2006 en el 9:20
> �Recuerde el mod_jserv?
S�, hago
> es tan sobre todo tiendas m�s peque�as o los reveladores individiual que se beneficiar�an de combinar el web server y los servidores del app.
No apenas tiendas m�s peque�as (qui�n no son un segmento insignificante tampoco) pero tambi�n tiendas m�s grandes que quieren probar el agua. Para una mejor adopci�n total ninguna lengua no debe ser restringida a casas m�s grandes solamente pero incluso ser f�cilmente accesible a los sitios de comercio electr�nico del mom-and-pop tambi�n.
Toma por ejemplo blogging softwares. Hay software blogging de Java de la alta calidad disponible para libre pero la mayor parte de nosotros uso WordPress o MovableType/Typepad. �Por qu�? Porque son f�ciles de fijar y de utilizar.