Blog

Servidor web V7

Introducción

Desde el comienzo del desarrollo de Velneo V7 hemos estado estudiando un conjunto de posibles opciones de cara a la implementación del servidor Web de la plataforma.

El objetivo principal era valorar si debíamos implementar un servidor web integrado en el vServer o conectarnos a uno existente. Estos eran los pros y contras de ambas soluciones:

Servidor Web propio

-PROS:

  • Facilidad y sencillez en la configuración y puesta en marcha.
  • Administración integrada en el propio vAdmin.

-CONTRAS:

  • Menor numero de funcionalidades y servicios web.
  • Menor flexibilidad y pocas opciones de configuración.
  • Menor posibilidad de escalabilidad.

Módulo para Servidor Web externo

-PROS:

  • Mayor compatibilidad y soporte de estándares web actuales y futuros.
  • Mayor flexibilidad e ilimitadas posibilidades de configuración.
  • Mayor protección de ataques web (al permitir aislar al vServer de internet).
  • Alta escalabilidad.

-CONTRAS:

  • Instalación y configuración de un servidor web externo a la propia herramienta.

La balanza se inclinaba claramente hacia la posibilidad de escoger un servidor externo, pero las exigencias pedidas eran muy altas:

– Multiplataforma nativa.

– Interfaz (API) en C/C++ clara y compatible con nuestras librerías.

– Soporte de todos los estándares web actuales y futuros(http 1.1, https, ssl, etc.).

– Garantía de futuro y popularidad.

Después de descartar varios candidatos había un único producto que cumplía con creces todas las características deseadas: Apache.

Nos hemos decantado por Apache, y para ello estamos desarrollando un módulo que conecte Apache con nuestro vServer exprimiendo al máximo todas las posibilidades que nos ofrecen ambos servidores, a dicho módulo lo hemos llamado vModApacheV7.

vModApacheV7 es un módulo para el servidor web Apache encargado de servir contenido de aplicaciones Velneo V7 vía Web.

Su principal función es actuar de puente entre el servidor de aplicaciones (vServer) y el servidor web Apache, de tal forma que Apache servirá por web el contenido que el vServer le suministra a través de este módulo.

¿Cómo servir contenido web desde una aplicación V7?

Si deseamos servir contenido web desde una instancia de una aplicación V7 debemos indicarle a Apache los parámetros necesarios para conectarse a dicha instancia mediante este módulo:

  • Dominio: Dominio web asociado a la instancia (lo que debe escribirse en el navegador para acceder por web).
  • Host: Ip o nombre de dominio donde está alojado el vServer que contiene la instancia.
  • Instancia: Nombre de la instancia.
  • Usuario.
  • Contraseña.

Estos parámetros se definen en un fichero de configuración de Apache llamado httpd.conf.

Una vez definidos los parámetros para cada una de las instancias se (re)inicia el Apache.

Cuando Apache se inicia recorre dicho fichero de configuración y se conecta a cada una de las instancias que van a servir contenido web, estas pueden estar alojadas en el mismo o en distintos vServers.

Una vez iniciado, desde cualquier navegador introduciendo el nombre de dominio asociado a cada instancia se puede consultar el contenido web que retorna.

¿Como funciona internamente?

  1. Apache al iniciarse recorre el fichero httpd.conf, reservando e inicializando un conjunto de recursos para cada instancia de aplicación definida en éste.
  2. Cuando le llega una petición web cuya url contiene un dominio asociado a una instancia, éste se lo indica al módulo, pasándole los parámetros necesarios para que se conecte a la instancia.
  3. El módulo se conecta a la instancia y obtiene el contenido que el programador de la aplicación desea servir por web (retorno web de procesos) y se lo devuelve a Apache, el cual a su vez se lo envía al navegador web que ha hecho la petición.

Diferencias respecto a Velneo 6.x

En Velneo 6.x el propio servidor de aplicaciones era también servidor web, mientras que en Velneo V7 lo es Apache.

Este aislamiento amplia el abanico de posibilidades:

  • Compatibilidad: El desarrollo de un módulo para un servidor web como Apache garantiza la máxima compatibilidad con los últimos protocolos (http, https, etc) y futuras tecnologías web.
  • Rendimiento: Liberar al vServer de servir web conlleva un aumento del rendimiento en la ejecución de aplicaciones, además el módulo utiliza la misma tecnología desarrollada para el vClient, aprovechando todas las mejoras y optimizaciones desarrolladas para éste (sistemas de caché, procesos en primer plano, etc.) lo que nos permite descargar aún más al servidor de aplicaciones.
  • Seguridad: permitiendo tener el vServer aislado de Internet, únicamente deber estar conectado (por protocolo VATP) a la máquina que contiene el Apache.
  • Servidor web V7 1

  • Escalabilidad: Ún unico Apache puede servir contenido procedente de distintos vServers y un vServer puede servir contenido a múltiples Apaches.
  • Servidor web V7 2

MiniFaqs

¿Cuánto me costará la intalación del servidor Web Apache?

Apache es software libre por lo que su instalación y utilización, tanto en software libre como en software propietario no implica ningún coste.

¿Podré utilizar el módulo con otros servidores web, tales como IIS?

No, hemos desarrollado un módulo únicamente para Apache, pues creemos que es el único servidor web que cumple todos los requisitos necesarios.

¿Es necesario tener instalado Apache para arrancar el vServer?

No, vServer no sabe de la existencia de Apache, es el módulo quien habla con vServer como si fuera un vClient más, y le devuelve los datos a Apache.

Apache sólo es necesario si se desea servir web.

¿Si recibo un a ataque web afectará al vServer?

No, esto es otra de las ventajas del nuevo sistema. Si realizan un ataque web será Apache quien lo reciba, pero el vServer ni se enterará, lo que nos permite, por ejemplo, activar otro Apache secundario para que continúe sirviendo la web mientras solventamos la vulnerabilidad del principal.

¿Se podrán servir web seguras (https) desde una aplicación desarrollada en Velneo V7?

Sí, el protocolo https está soportado por Apache, por lo que estará disponible para nuestras aplicaciones.

32 thoughts on “Servidor web V7

  1. ¿Entonces serán posibles estas dos opciones?

    1º Utilizar cualquier lenguaje de desarrollo web para apache y acceder con vOdbc al vServer.

    2º Devolver al servidor apache contenido web directamente. Es decir, poder llamar .pro y .bus y que apache y vServer se entiendan con este modulo.

    Si me equivoco me corregís.

  2. Buenas.

    En mi opinión creo que habeis tomado la mejor solución posible, felicidades nuevamente.

    Realmente la función de ese módulo que estais desarrollando ¿sería más o menos lo que actualmente se hace con proxy inverso no?, si es así ¿que diferencia hay entre hacer un módulo que comunique vServer v7 y Apache, y el proxy inverso que se hace actualmente?.

    Un saludo.

  3. Hola Francisco, ambas opciones serán posibles, aunque siempre es más recomendable utilizar la segunda opción, pues aprovecha toda la potencia de la plataforma.

  4. Hola!!!

    Se nota que habéis pensado en todos los detalles… vuestra experiencia se ve reflejada.

    Pienso que habéis tomado una buena decisión, sobre todo teniendo en cuenta que los ataques son cada vez más frecuentas.

    Muchas gracias.

    Un saludo.

  5. Hola de nuevo,

    Hay diferencias muy sustanciales respecto a un sistema de proxy inverso:

    La comunicación entre Apache y vServer no será mediante http sino mediante vatp con las mejoras que esto conlleva.

    Pero la principal ventaja es que el módulo es a todos los efectos un cliente más, visible como un enganche «Apache» desde el vAdmin.

    Esto permite aprovechar al máximo toda la tecnología desarrollada para el vClient.

    Por ejemplo, un proceso en primer plano se ejecutaría diréctamente en el módulo, sin si quiera conectarse al vServer, lo mismo sucedería cuando se recibe una petición de registros que ya han sido pedidos previamente, el módulo los tendrá en caché y los devolverá directamente sin volver a pedirselos al vServer.

    El uso de protocolo propio entre ambos servidores garantiza seguridad y robustez, mientras que el sistema de caches, y procesos en primer plano en el módulo descargan de trabajo al vServer.

    Un saludo.

  6. Buenas.

    Ahora si que veo la diferencia claramente entre un sistema y otro, y la verdad es que es fantástico lo que estais desarrollando vModApacheV7, y supone un gran salto en el ámbito web para la plataforma.

    Teneís ya pensada alguna fecha para que se pudiera probar esto, ya que supongo que para la próxima beta no estará.

    Un saludo.

  7. Gran noticia.

    La mejor decisión que podía tomar Velneo al respecto. Enhorabuena.

    Por fín abandonamos http1.0!!!

    Por otra parte, con lo fácil que era ahora montar webs distribuidas, cada cliente con su vServer sirviendo su web, con lo que ello conlleva al evitar cuellos de botella y la baja inversión necesaria en recursos hardware, ahora pasaremos a obligatoriamente depender de un Apache.

    Ahora me tocará o montar un Apache que centralice recursos o montar un apache en cada cliente.

    Me lo pensaré.

    Desde luego, de cara a la plataforma y su evolución lo mejor que se podía hacer.

    De cara a mis clientes no creo que vaya a ser un proceso «transparente».

    Me lo pensaré con calma.

    Un saludo,

    DomK

  8. Buenas tardes.

    Aún no hay fechas definitivas pues la fase de desarrollo no ha finalizado, pero esperemos tener una versión lista lo antes posible, sino es para esta beta para la siguiente.

  9. Tenía una infinidad de preguntas con respecto a la parte web con V7. Luego de leer esto sólo me queda una duda: PARA CUANDO!!???.

    Realmente muy bueno. Fuerza y adelante.

  10. Siempre he pensado que esta es la mejor opción, integrar la mejor plataforma de bbdd con el mejor servidor web.

    De esta forma, cada parte se centrará en su producto; Velneo en su módulo y el equipo de Apache con el resto.

    Esto también nos beneficia en que si alguna de las partes detecta un bug, publica una actualización de seguridad o implementa nuevas funcionalidades solo habrá que actualizar esa parte, siendo transparente al resto.

    Ahora Velneo en Web, avanzará al mismo ritmo que el resto de lenguajes.

    Un saludo.

  11. Tal vez se halla hablado sobre nº de puerto de VTAP, en V7 será único como hasta ahora (690) ya que sobre escalabilidad decis: «Ún unico Apache puede servir contenido procedente de distintos vServers…», si estos vServers estan en una misma red que sale con la misma IP, como se resuelve eso?

    De todas formas zapatero a tus zapatos, los web que den web y los datos que den datos.

    Saludos

  12. Creo que es la forma correcta de enfocarlo.

    La pregunta que me surge es como crearemos los procesos, será como al principio todo en el proceso o creareis el objeto componente HTML.

    Si vamos a tener un objeto las mayores limitaciones que considero que tiene en V6 es no poder modificarlo en ejecución, con esta posibilidad seria una forma muy completa de crear nuestras WEB.

    Saludos.

  13. Se parece a lo que nosotros habiamos diseñado con la 6. El servidor de Velneo sirve los datos y el servidor Web puede ser cualquiera trabajando en .asp o en php. El servidor web hace peticiones al servidor web velneo a través de .pro pasando los parámetros que se precisaban, y este los delvovía en xml. De esta manera abstraiamos el servidor de datos, que puede cambiado en cualquier momento.

    Con este planteamiento el servidor web de velneo solo «gasta» un engache para web, pudiendo servir multitud de peticiones con una única licencia, la pregunta es cómo se realiza esto con el nuevo planteamiento?

  14. Impresionante, si hasta ahora se podian hacer maravillas para la web, a partir de ahora que tiemble internet. Me estoy imaginando la cantidad de combinaciones posibles entre vserver y apache, en local, en remoto, en linux, en mac, mod_rewrite, dominios virtuales etc.. y la verdad es que no le encuentro el limite. Si además le sumamos la virtualización, el balanceo de carga etc.. podemos montar un datacenter exclusivo para aplicaciones velneo con un rendimiento increible.

    Buen trabajo

  15. El número de puerto del protocolo vatp es el 690 por defecto, pero en V7 este puede cambiarse para que el servidor escuche en cualquier otro puerto, por lo que si tenemos varios vServers que están en una misma red que sale con una única IP, y queremos tener acceso a ellos desde fuera, únicamente tenemos que iniciar cada vServer con un número de puerto distinto y luego mapear cada puerto a cada máquina en el router de salida.

    Debido a la versatilidad y sencillez de los procesos, en esta primera fase de desarrollo el contenido web irá integro en el retorno de proceso, posteriormente se implementarán nuevos objetos para facilitar la generación de contenido web.

  16. Hola Jcmar,

    Como En Velneo 6.x la web únicamente consume un enganche, en velneo V7 es el módulo (vModApacheV7) el que consume un puesto como si fuese un cliente más.

    Respecto al sistema que comentas de envio de datos xml desde un vServer hacia un Apache, podrás seguir manteniéndolo con V7, solo que los datos xml viajarán a través de protocolo vatp, en lugar de http.

    Este sistema no afecta a la plantilla vWeb, esta seguirá existiendo en V7. La única diferencia es que ahora el retorno de los procesos web será enviado a Apache mediante el módulo, pero esto será transparente al programador.

  17. Hola.

    Es la evolución lógica… aunque también pienso que voy a echar en falta el «todo-en-uno» que suponía el antiguo vMotor. Ahora, imagino, tendré que preocuparme de la versión del Apache, de la versión del módulo… y de conocer Apache. Más variables y más complicación, aunque no dudo de que el resultado, globalmente hablando, sea mejor.

    Lo que pasa es que… si a todo lo nuevo que hemos visto (que es bastante, y está aún por terminar de desarrollar) le sumamos lo que nos queda por ver (i.e., el módulo vModApacheV7)… y el vODBC… y… ¿cuándo tendremos una versión de trabajo de V7??? (sin ánimo de criticar, es un suspiro al vacío)

    En fin, esperaremos… Saludos,

    Fran Varona

  18. Domk, Fran Varona y, modestamente, yo, añoraremos el sencillo y eficiente servidor WEB, por los motivos expuestos por ellos, y yo, porque tendré que aprender muchísimo mas sobre WEB, Apache y php, asp, etc.

    ¡Con lo fácil que era toda la instalación, y lo demás con saber XHTML y CSS, y un pelín de javascript!

    ¿Y por qué no, tener los dos métodos de servir WEB?

    ¿Es que nos van a jubilar a todos los síux?

  19. Es algo que me preguntaba hace unos días, ¿qué pasá con la web en la v7?. Ha sido una grata sorpresa el ver que ahora podremos aprovechar la potencia de estos dos mostruos. Claro que tiene inconvenientes como comentá Domk. Pero es un camino acertado, dado que da mucho juego de posibilidades.

    Manugc

  20. Este cambio no afecta a ninguna aplicación de cara a servir web, es transparente al programador de Velneo.

    De cara a servir informes como páginas web, la única diferencia es que para visualizar el informe html el navegador web se conectará a un apache, en lugar de al servidor de aplicaciones.

  21. Es muy buena noticia.

    Por fin nos vamos a poder quitar de encima los» vParches» de vCSS, vPost …

    No se me entienda mal, el servidor html de velázquez no estaría pensado en su día para soportar determinadas tecnologías que por entonces se verían lejanas, y los «vParches» (como yo los llamo cariñosamente) nos han venido solucionando la papeleta ante esas carencias. Pero son parches que no solucionan completamente esas carencias.

    Al rey lo que es del rey. Si Velneo es una herramienta de desarrollo, lo que tiene que procurar es ser de las mejores herramientas RAD del mercado. Si Apache es el mejor servidor HTTP freeware que hay en el mercado, pues para que se va a reinventar la rueda, se implementa un módulo que actúe de pasarela y voooaaalaaaa, habemus servidor HTTP para V7.

    Enhorabuena. Me parece una idea fantástica.

    Saludos. Darío.

  22. Es posible que no sen entendiera mi sugerencia, por estar envuelta en un malísimo chiste.

    Quiero decir: Me gustaría que pudieran mantenerse las dos maneras de servir WEB:

    1- Mediante el servidor de la V7, incluso con las limitaciones actuales arreglado lo del Css. Sistema que podríamos llamar para Síux (repito el chiste por si alguien no lo había pillado)

    2- A través del servidor WEB Apache

    No se me oculta que pido, quizá, demasiado pero para el equipo de Velneo que ha hecho lo que ha hecho….,¿ se van a amilanar ahora?.

    Luis, te agradecería un comentario, aunque me imagino que será desfavorable.

  23. Hola Juan, en V7 solo mediante este módulo se podrá servir web. Como se comenta en el artículo, el nuevo sistema tiene en su contra la incomodidad que genera no tenerlo todo integrado, pero tiene muchos más pros que contras y por ello nos hemos decantado por este.

    Una vez desarrollado el módulo, podremos centrarnos única y exclusivamente en mejorar nuestra propia tecnología (protocolo vatp, etc.) Delegando en el equipo de Apache todo el trabajo correspondiente a nuevas funcionalidades y mejoras en el http.

    La integración de un servidor web dentro de la plataforma (paralelamente al módulo), no es una opción que hayamos descartado por completo, pero en las primeras versiones de la herramienta no se llevará a cabo

    Un saludo.

  24. Hola a todos:

    Despues de haber leido el artículo y ver el video, se me plantea la siguiente duda, cómo se debería construir una URL para el servidor web Apache enlazado con V7?. Podremos segguir haciendo llamadas a procesos, búsquedas, etc?

    Como quedaria esta IRL compuesta paara la V6X?
    dominio/cgi-vel/app/LOGIN-ws.bus?IDU=1&IDP=2

    Sería así?
    dominio/LOGIN-ws.bus?IDU=1&IDP=2

    Un saludo.

  25. Hola A.Amezaga:

    La sintáxis será similar a V6, podremos referenciar procesos, busquedas, etc. pero como bien comentas ya no será necesario la pasarela cgi-vel/ para servir webs. Tabmbién podrán enviarse variables por POST además de por GET.

    Un saludo.

  26. Comprendo el cambio, y lo veo necesario. PERO me gustaba vacilar diciendo que Velazquez era servidor de disco, aplicaciones y web mas ligero y rapido. como dice esa cancioncilla «en sus manos tiene todo el mundo». Y que no dependias de tecnologias externas es decir una aplicación desarrollada en un lenguaje ‘a’ contra una base de datos ‘b’ y servida por ‘c’.
     
    Que todo sea por las urls amigables el https, certificados digitales, y aprovechar esas tecnologías existente, por que life is soft, PERO vivir es convivir, y si v7 se aisla del mundo no volará lo alto que se merece, felicidades por los plugins, seguir así.
     

Dejar un comentario