John Hagel y John Seely Brown (2001) hacen referencia a la arquitectura basada en servicios Web (Web Services) como la “nueva arquitectura”, señalando incluso el inicio del final de los sistemas de información propietarios y el “amanecer” de los servicios compartidos. W3C define un Web Service como un sistema de software diseñado para soportar la interacción e interoperabilidad máquina a máquina sobre una red. Por lo tanto, los servicios Web tiene como principal objetivo proporcionar una forma estándar de interoperabilidad entre diferentes aplicaciones de software que se ejecuta en una variedad de plataformas. Desde mi parecer, a continuación indico cuáles han sido las principales arquitecturas  relacionadas con los Web Services.

Service Oriented Architecture (SOA)

El objetivo de SOA es básicamente la colaboración a través de servicios, los cuales se publican y están disponibles para la invocación en el Service Bus. La adopción de SOA es fundamental para mejorar la agilidad de negocios y la flexibilidad TI prometida por los Web Services. Estos beneficios son entregados por la arquitectura de servicios desde una perspectiva tecnológica y la adopción de protocolos de Web Services, además requieren de un entorno orientado a servicios.

Los resultados han sido que muchas empresas los utilicen en sus plataformas comerciales y que muchas aplicaciones se diseñen y desarrollan bajo una arquitectura orientada a servicios. Además, SOA representa también una oportunidad para el desarrollo incremental, despliegue, mantenimiento y extensión de las aplicaciones de negocios (Natis, 2003).

Representational State Transfer (REST)

Según Tyagi (2006), en el mundo de los Web Services, REST es un “idioma” clave de diseño que abarca una arquitectura cliente-servidor sin estado en el que los servicios web son vistos como recursos y pueden ser identificados por sus direcciones URL. Los servicios web REST se construyen usando HTTP, URIs, XML, JSON, Atom, etc. Los clientes de que utilizan estos recursos acceden a una representación particular mediante la transferencia de contenido de la aplicación usando métodos remotos que describen la acción que debe realizarse en el recurso. REST es una descripción analítica de la arquitectura Web existentes, y por lo tanto la interacción entre el estilo y el protocolo HTTP parece perfecta. REST tiene como principales principios u objetivos la utilización de los estándares Web, tales como HTTP y URI, y aprovechar la arquitectura de la Web para su beneficio.

Los resultados de REST es que actualmente existen una gran cantidad de aplicaciones basadas en REST, que prácticamente cualquier servicio es accesible desde una petición GET en HTTP, en contraposición a SOA que es más restrictiva. De acuerdo con Wikipedia, algunas de las aplicaciones las encontramos en blogosfera, Amazon.com, eBay, Bloglines, Yahoo, Microsoft, Twitter, Google Apps, SalesForce, etc.

Software as a Service (SaaS)

“Software como servicio (del inglés: Software as a Service, SaaS) es un modelo de distribución de software en donde la compañía de tecnologías de información y comunicación (IT) provee el servicio de mantenimiento, operación diaria, y soporte del software usado por el cliente” (Wikipedia, 2010). Por lo tanto, SaaS es una aplicación “hospedada” en un servidor remoto y accedida desde Internet. Muchas de estas son software de negocios y típicamente son de menor costo para que el negocio pueda tener software especializado y que muchos usuarios lo puedan operar. Las características del software como servicio incluyen: acceso y administración a través de una red, actividades gestionadas desde ubicaciones centrales permitiendo a los clientes el acceso remoto a las aplicaciones mediante la Web, la distribución de la aplicación es más cercana al modelo uno-a-muchos (una instancia, múltiples usuarios) que al modelo uno-a-uno, actualizaciones centralizadas y frecuente integración con una red mayor de software de comunicación.

Los resultados es que es una tecnología emergente, y tienen ventaja sobre SOA de que las aplicaciones de software se comunican entre sí. Gartner espera que para el 2010 el 25% del software de negocio sea entregado en una arquitectura SaaS. SaaS está llamando mucho la atención en estos días, se puede decir que SaaS está marcando la pauta para muchos enfoques de modelos de negocio que van desde las Green TIs, plataformas como servicios, Cloud-computing, Grid-computing, Application Service Provider (ASP), etc. Además, según Singla (2009), SaaS envuelve muchas aplicaciones expuestas en la red como son software para soporte a clientes, sistemas financieros, comercio electrónico, sistemas de pago, inteligencia de negocios, administración de ventas y mercadotecnia, entre otras.

Conclusión

Como se puede apreciar, las tres arquitecturas son tecnologías basadas en Web Services que ha emergido en la última década, destacando precisamente a SOA como una arquitectura para la integración de servicios, REST como una arquitectura simple y ampliamente utilizada por su facilidad de acceso todo desde una petición HTTP sin ser restrictivo como lo es SOA, y por último, Software as a Service, la cual envuelve muchas aplicaciones, que en estos días los departamentos de TIs la están tomando mucho en cuenta por las oportunidades de negocio que esta ofrece.

SOA, REST y SaaS en un mapa conceptual de sistemas distribuidos (Dahan, 2008)

Fuentes consultadas

Booth, D.; Hass, H.; McCabe, F.; Newcomer, E.; Champion, M.; Ferris, C. & Orchard, D. (2004). Web Services Architecture. W3C Working Group. From http://www.w3.org/TR/ws-arch/

Dahan, U. (2008). Distributed Systems Conceptual Map.  The Software Simplist, Enterprise Development Expert & SOA Specialist. From http://www.udidahan.com/2008/08/04/distributed-systems-concept-map/

Hagell, J. & Brown, J. S. (2001) Your Next IT strategy. Harvard Business Publishing Corporation. From http://tailieu.athena.edu.vn/Ky%20Nang%20IT/Kinh%20Doanh%20IT/Your%20Next%20IT%20Strategy%20-%20Harvard%20Business%20Review.pdf

Natis, Y. V. (2003). Service-Oriented Architecture Scenario. Gartner Reseach. (ID: AV-19-6751). From http://www.gartner.com/resources/114300/114358/114358.pdf

Singla, V. (2009). The Overlapping Worlds of SaaS and SOA: How SaaS and SOA will enable “IT as a Service”. Cloud Computing Journal. From http://www.dosideas.com/noticias/java/314-introduccion-a-los-servicios-web-restful.html

Sprott, D. & Wilkes, L. (2004). Understanding Service-Oriented Architecture. Microsoft Architect Journal. From http://msdn.microsoft.com/en-us/library/aa480021.aspx

Tilkov, S. (2007). A Brief Introduction to REST.InfoQ. From http://www.infoq.com/articles/rest-introduction

Tyagi, S. (2006). RESTful Web Services. Oracle. From http://java.sun.com/developer/technicalArticles/WebServices/restful/

WIKIPEDIA. (2010). Representational State Transfer. Wikipedia, the free encyclopedia. From http://en.wikipedia.org/wiki/Representational_State_Transfer

Compartir/guardar

Con base a lecturas en Wikipedia y analizando procesos de desarrollo de algunas empresas encontré que típicamente el proceso de desarrollo de software tradicional y de Web no varían, es decir, generalmente pasan por requerimientos, diseño, implementación, pruebas e implantación. En particular, coincido con G. Engels, M. Lohmann & A. Wagner (2003), quienes señalan que los programadores de aplicaciones web se enfrentan con más frecuencia a nuevos requerimientos (o cambios en estos) que los desarrolladores de sistemas de software tradicional. Por lo tanto el proceso de desarrollo de software tradicional tiene que ser adaptado cuando se desarrolla una aplicación para web de acuerdo a las siguientes aspectos.

• La duración del proyecto en ciclos de desarrollo son cortos, es decir, de tres a seis meses promedio comparado con las aplicaciones tradicionales que son de 12 a 18 meses.
• Los requerimientos para aplicaciones web cambian o emergen durante el desarrollo del proyecto.
• Las liberaciones a plazos fijos conduce a una metodología de desarrollo basada en prototipos.
• Se presta para el desarrollo paralelo en diferentes versiones, es decir, que muchas actividades en el diseño, implementación y pruebas pueden trabajarse en paralelo para diferentes versiones.
• La reutilización e integración es necesaria porque la presión por el tiempo conduce a que se desarrollen componentes reutilizables y que se puedan integrar en otros proyectos.
• Los niveles de complejidad en el desarrollo web es de menor en las primeras etapas, y conforme se van integrando mas perspectivas la complejidad aumenta.

De acuerdo a lo anterior, considero que no se recomienda que los especialistas del proceso de desarrollo de software desarrollen una aplicación web porque esta demanda grupos multidisciplinarios, mucha comunicación y coordinación, además de que los grupos son más pequeños y con semejante expertis.

Fuentes consultadas:

G. Engels, M. Lohmann & A. Wagner.(2006). Web Engineering: The Discipline of Systematic Development of Web Applications. (pp 197-218). John Wiley & Sons.

Wikipedia. (2010). Wikipedia, the free encyclopedia. From http://en.wikipedia.org/wiki/Software_development_process, http://en.wikipedia.org/wiki/Agile_web_development y http://en.wikipedia.org/wiki/Software_development_methodology

Outsource2india. (2010). Application Development Process. From http://www.outsource2india.com/software/process.asp

B. Alexander. (2010). Macronimous. Site Development Process. From http://www.macronimous.com/resources/web_development_life_cycle.asp

Compartir/guardar

1. Solo porque puedes no significa que debas.  Actualmente hay muchas tecnologías Web y no porque haya deban de utilizarse (por ejemplo Ajax, Flash, etc.); la pregunta que deberia hacerse un diseñador Web es: “‘ ¿La tecnología agrega valor al sitio o solo se utiliza para mostrar que hay novedad? “.
2. Hay casi siempre una excepción. Un diseñador Web debe tener cuidado de excluir una tecnología Web, ya que si bien, no funciona para muchos usuario, quiza haya un grupo que lo prefiera (Por ejemplo, un logotipo animado con flash).
3. El último juez es el usuario.  Opiniones durante el diseño del sitio nunca faltan (del diseñador, del jefe, del programador, etc); pero la conclusión es que el sitio debe tener sentido para el usuario, por lo tanto el sitio debe ser diseñado teniendo en mente al usuario.
4. Cruzar experiencias es algo que un diseñador Web debe esforzarse. Un dieño Web profesional requiere entender las necesidades del usuario,  independientemente de los aspectos técnicos y estéticos que el sitio pueda tener.
5. La humildad es el mejor enfoque. Siempre va a haber diseñadores con diseños de sitios más atractivos, por lo tanto el aprender de los demás fortalece las habilidades.
6. Es imposible complacer a todos. Un diseño nunca va a dejar a todos contentos; y todo mundo tiene una opinión. Sin embargo, hay una línea delgada entre hacer feliz a la mayoría y tratar de crear un sitio que realmente sea eficaz en la comunicación.
7. Tratar de estar en el tope de las especificaciones y estándares. Las especificaciones y estándares Web cambian constantemente, por lo tanto un diseñador Web debe tener una comprensión básica de las últimas tecnologías, las cuales afectarán el trabajo futuro.

Además de las reglas básicas, un diseñador Web debería tomar en cuenta que debe haber tres factores en un sitio:

1. La estéticca. Qué tan profesional y consistente es el sitio con el negocio.
2. La usabilidad.  Qué tan facil y rápido el usuario encuentra la información o ejecuta sus tareas.
3. La funcionalidad. Qué tanto funciona el sitio y permite a los usuarios resolver sus problemas.

De lo anterión se concluye que un sitio Web es exitoso si cumple con tres cosas: que le guste al usuario,  lo use  y le funcione.

Compartir/guardar

1. Saber por qué quieres tener un sitio web. Demasiadas organizaciones construyen sitios sin saber siquiera el por qué. Hay que contestarnos las siguientes preguntas: ¿Cómo ayudará tu sitio web a la organización? ¿Cómo o de que manera ayudará a los visitores?.
2. Construir el sitio web para el usuario. No para ti. Los usuarios llegan al sitio con un propósito en mente, y tu trabajo es ayudarles a completar su propósito. Esta es la principal lección que hay que aprender: tu sitio web es para los usuarios. Ellos llegan al sitio con un propósito en mente, entonces, tu trabajo es ayudarles a conseguirlo.
3. Cumplir con una necesidad. Si quieres atraer visitores lo primero que tienes que hacer es cumplir una necesidad. La necesidad más específica y la solución más efectiva,  lo que la mayoria de las personas buscan llevar a cabo.
4. Escribir un plan. Es tan simple que a menudo es ignorado: tu deberías hacer siempre un plan – y escribirlo – antes de iniciar el trabajo en un sitio. Esto te ayuda a pensar en las decisiones y la estimación de costos. Además, asegura que los miembros del equipo estén de acuerdo con lo que, exactamente, estén construyendo.
5. Colabora.  Cada sitio exitoso es un esfuerzo de colaboración, que requiere que personas de diferentes disciplinas – diseño, ingeniería, marketing- trabajen juntos. Pero el pensar de forma diferente, su trabajo diferente, y hablar lenguas muy diferentes hace que ellos pueden necesitar ayuda.
6. Poner atención en el tráfico del sitio. Al ver lo que hacen los visitantes – de dónde proceden, en donde hacen clic, cuánto tiempo permanecen, cuando salen – se puede ver qué es lo que funciona (y qué no) en tu sitio.
7. Deja a tu sitio evolucionar. Después del lanzamiento de tu sitio web, el trabajo real inicia. Hay que ver como es usado y gradualmente hacer los cambios para satisfacer mejor las necesidades de los usuarios.
8. Haz tu sitio fácil de usar. Es una ecuación probado-y-comprobado. Mientras más fácil sea tu sitio web de utilizar, más personas lo usarán. Así que si quieres ganar impulso, haz tu sitio más simple y más sencillo, por ejemplo:  tomar decisiones obvias, elegir nombres claros, y seguir las convenciones de diseño que los usuarios han asumido.
9. Probar, probar, probar! Es difícil predecir lo que ocurrirá cuando un sitio aparece en diferentes navegadores o es utilizado por diferentes personas. Por lo tanto, asegúrete de probar! Probar el diseño y la tecnología en los distintos sistemas. También comprobar si el sitio es usable: ¿Las personas lo entienden? ¿Pueden completar sus metas?.
10. Utilizar el email para mantenerse en contacto con los visitores. Las personas visitan a tu sitio solo cuando ellas lo recuerdan. El email es la mejor forma para recordarselo. No importa que tipo de sitio tengas, el email es la mejor forma para hacer que las personas regresen. Pero recuerda: hay una linea delgada entre el recordatorio y el hostigamiento. No exageres!.
11. Mantente concentrado (enfocado). Es fácil pensar en un mil cosas que hacer, dado todo el tiempo y los recursos. Pero, no siempre es mejor. Desde el punto de vista del usuario, un buen sitio web es un sitio Web simple, y para características adicionales sólo hay que ponernos en sus zapatos.
12. Acelérarlo!. Puedes hacer todo lo demás correctamente, y aún falla. Si las páginas se cargan lentamente, mejora la velocidad de tu sitio.

Fuente: “The Unusually Useful Web Book” by June Cohen

Compartir/guardar

• Navegación fácil y ligera

Los enlaces de navegación juegan un papel muy importante lo cual determina el tiempo en que un visitante permanece y explora el sitio.

• Diseño del sitio limpio

Un diseño limpio con suficiente espacio en blanco mejora la apariencia del sitio. Tratar de mantener la atención en su contenido, utilizar una plantilla para ello. Utilizar fuentes que estarán disponibles en cualquier equipo para evitar un mal estado del sitio.

• Optimización de tiempos de carga
  

Asegurar que el tiempo de carga de las paginas sea bajo. Para esto es recomendable hacer

• Minimizar gráficos, scripts y peliculas (flash).
• коли под наемOptimizar el contenido HTML y codigo script.
• utilizar archivos Server Side Include (SSI) tando donde sea posible.

• Diseñar para todo tipo de resoluciones de pantallas
  

Un sitio que es fácil de utilizar siempre alienta a los visitantes a permanecer y leer su contenido. Para sitio con mucho contenido es muy importante que el desplazamiento requerido sea reducido.  El diseño de una página que se ajuste a cualquier tipo de resolución asegura de que todos los visitantes aprecien un sitio profesional y atractivo.

• Asegurar la escalabilidad del sitio web
  

Asegurar que el código y diseño sea escalable dado el avance constante de la tecnología en plataformas.

• Compatibilidad con los browsers
  

Revisar que el sitio se pueda navegar desde Internet Explorer 5+, Firefox 1.0, Opera 7.0 y Netscape Navigator 6+ ya que ellos conforman el 95% del total de browsers del mundo.

Compartir/guardar

Ajax, Adobe’s AIR, Microsoft’s Silverlight, y Sun’s JavaFx son plataformas recientes para la creación de aplicaciones web ricas que sacan beneficio de las fortalezas de los individuos para crear nuevas experiencias de usuario altamente apremiante que antes no era posible. Aquí hay algunos tips de alto nivel para la construcción de aplicaciones Web 2.o.

• Entender las bases de Web 2.o.
• Reunir un equipo de desarrollo que esté dispuesto a aprender.
• Consumir tiempo para estudiar la competencia.
• Obtener el conocimiento de tus clientes para ofrecer lo que realmente necesitan.
  
• No perder de vista los fundamentos del Web 2.0компютри втора употребамебели
• Usar las más recientes herramientas, tecnologías, aplicaciones, plataformas y ganar terreno en lo que ellas hacen.

Mas información (en inglés)

Compartir/guardar

• TechCrunch Es un blog lider en recursos Web 2.0 con inovador perfil de productos y compañias de internet.
• Mashable: Es un blog de noticias que incluye secciones dedicadas a MySpace, YouTube, Bebo, Facebook y Xanga.
• ReadWriteWeb: Este blog proporciona noticias, revisiones y análisis de tecnologías web.
• GigaOM: Es un blog de análisis y noticias de tecnología, su editor Om Malik es escritor formador de Business 2.0, Red Herring y Forbes.com.
• Dion Hinchcliffe’s Web 2.0 Blog: Es un blog de análisis y noticias Web 2.0.
• Matt Cutts’ Blog: Es un blog de Matt Cutts, ingeniero de software de Google, y toca temas de gadgets, Google y SEO.
• O’Reilly Radar: Es un blog de Web 2.0, open source, tecnologías emergentes y más.
• SearchEngineLand: Es un blog de noticias de motores de búsqueda (google, yahoo, microsoft, etc.).
• SearchEngineWatch: Noticias y análisis de la industria de los motores de búsqueda; incluye blogs, tutoriales, foros y más.
• Deitel Resource Centers: Es un repositorio de recursos de Web 2.o y de internet que incluye ligas, tutoriales, demos, herramientas de software grátis, artículos, libros, videos, podcasts, blogs, feeds RSS, etc.

Compartir/guardar

Regla 1: Reducir el número de solicitudes HTTP. Hay técnicas que ayudan a reducir el número de solicitudes HTTP sin comprometer el diseño de las páginas.

Regla 2: Usar un Content Delivery Network (CDN). Un CDN es una colección de servidores web distribuidos a través de múltiples localizaciones para entregar contenido a los usuarios más eficientemente.

Regla 3: Agregar un Expirer Header. Se trata de asegurar que los componentes sean configurados para maximizar las capacidades del caché del browser.

Regla 4: Componentes Gzip. Una variable que afecta el desempeño es el tamaño de la respuesta HTTP. Los componentes Gzip reducen el tamaño de los paquetes de respuesta que son transmitidos del servidor al cliente.

Regla 5: Poner las hojas de estilo (CSS) en el inicio. Al final de varias pruebas e investigación se ha encontrado que para cuestiones de desempeño se debe de colocar las CSS’s en el HEAD usando la etiqueta LINK.

Regla 6: Poner los scripts al final. Lo opuesto a las CSS’s, es mejor mover los scripts hacia el final de las páginas (siempre y cuando sea posible). Esto permite la renderización y descarga paralelamente.

Regla 7: Evitar expresiones CSS. Las expresiones CSS son una poderosa (y peligrosa) forma de poner propiedades dinámicamente. Un problema es que no todos los browser las soportan y otro es que podrían ser re-evaluadas cada vez que la página cambia, por redimensionamiento, scrolling, movimiento del mouse, clicks, etc.

Regla 8: Hacer externos los Javscripts y CSS’s. Esta regla hace que los componentes Javascript y CSS puedan ser cachados en el browser del usuario y ponerlos internos hace ineficiente la ventaja del cache del browser.

Regla 9: Reducir los DNS Lookups. Un Domanin Name System (DNS) tiene el rol de mapear nombres de dominios en direcciones IP. El browser no descarga nada hasta que el DNS resuelve completamente el nombre del dominio. Este es tiempo que las páginas gastan en hacer DNS lookups. Reduciendo el número de hostnames únicos en la página web se reduce los DNS lookups pero tambien reduce la descarga paralela.

Regla 10: Minimizar el JavaScript. Minificación es la práctica de remover los caracteres innecesarios del código para reducir su tamaño y de esta manera mejorar el tiempo de carga.

Regla 11: Evitar redireccionamientos. Un redireccionamiento (redirect) es usado para enrutar los usuarios de una URL a otra. Regularmente son para documentos HTML pero también para requerir componentes (imagenes, scripts, etc.) en las páginas.

Regla 12: Remover scripts duplicados. Incluir dos veces el mismo archivo Javascript afecta el desempeño. Este error no es raro, una revisión de sitios web mostró que CNN y YouTube contenían un script duplicado. Asegurarnos que los scripts sean incluidos una sola vez.

Regla 13: Configurar ETags. Los Entity Tags (ETags) son un mecanismo que los servidores web y browser utilizan para validar los componentes cachados.

Regla 14: Hacer AJAX cachable. Ajax tiene un gran impacto en el mundo Web 2.0 y con Ajax se puede lograr una mejora importante en el rendimiento. Aunque las solicitudes Ajax no son cachables, asegurarnos de que estas sigan los lineamientos, expecialemente de que tengan un futuro lejando de Expires Header.

Compartir/guardar

1. Evitar hacer supocisiones acerca de las habilidades físicas, mentales y sensoriales de los usuarios.

2. Las tecnologias de los usuarios son capaces enviar y recibir texto. Esto es algo que siempre podremos dar por hecho.

3. El tiempo y la tecnología pertenecen a los usuarios, no a nosotros. Nunca debemos de tomar el control de ninguno de estos si no existe una buena razón para hacerlo.

4. Proporcionar buenos textos alternativos para cualquier contenido que no sea texto.

5. Usar ampliamente la tecnologia disponible para alcanzar al público.

6. Usar lenguaje claro para comunicar el mensaje.

7. Hacer sitios usables, encontrables, y navegables.

8. Diseñar contenido con enfoque semántico y mantener la separación entre contenido y presentación.

9. Progresívamente mejorar el contenido básico agregando características adicionales; pero permitir a los usuarios descartarlas cuando ellos no puedan o no quieran usarlas.

10. En las nuevas tecnologías web aplicar estos mismos principios para hacerlas accesibles.

Compartir/guardar

Compartir/guardar