Bloque 3-1

Argumentar en el blog propio la utilidad de los servicios web, y qué posibilidades tienen el futuro


He encontrado algunas cosillas que responden perfectamente (o más o menos) a lo que pide el ejercicio:

En cuanto a la utilidad he visto:

Lo primero que debéis saber, si no lo conocéis ya, es que la tecnología web 2.0 os permite utilizar determinadas aplicaciones web en línea de una manera muy sencilla ya que, en la mayoría de los casos, tan sólo habéis de disponer de un navegador y una conexión a Internet. Así, no necesitáis descargaros miles de programas en vuestro ordenador para realizar todas aquellas actividades que se os pasen por la cabeza o necesitéis por motivos de trabajo.

Además, os permite compartir todo tipo de contenidos, es decir, colgarlos o bajarlos desde Internet y crear o modificar contenidos entre distintos usuarios. Estos servicios web 2.0 son muy sencillos de utilizar y van desde el nivel más básico hasta el más avanzado, aunque muchas veces en este último caso seguramente se os solicite pagar algún sumplemento. Las aplicaciones más básicas suelen ser gratuitas. Aunque la gran mayoría de estos servicios están en versión “beta“, todas ellos suelen funcionar a la perfección.

Si quereis ver algo más os dejo el enlace aquí

En cuanto a la visión futura tenemos

El trabajo sobre la plataforma de servicios Web continuará en el futuro, y aparecerán mejoras en tres áreas fundamentales. En primer lugar, se añadirán servicios de más alto nivel. Todo el mundo está de acuerdo en que debe existir un modo estándar de asegurar servicios Web, rutear mensajes, garantizar una entrega fiable de mensajes, definir semántica transaccional, etc. Estas características de propósito general se expanden más allá de los dominios del problema y no hay ninguna razón por la que cada desarrollador de servicios Web deba implementarlas individualmente. Microsoft, IBM y otros están realizando mucho trabajo en estas áreas. La iniciativa Global XML Web Service Architecture (GXA) define un conjunto de especificaciones sobre cómo implementar estos servicios de infraestructura en términos de mensajes SOAP (por ejemplo, de un modo neutral respecto del protocolo de transporte.

En segundo lugar, seguirán estandarizándose especificaciones. El ciclo de vida de las especificaciones de servicios Web típicamente progresa desde una propuesta hasta un estándar de facto y desde éste hasta un estándar real. Con SOAP 1.2 y WSDL 1.2 las peculiaridades finales están siendo elaboradas de las especificaciones SOAP y WSDL y algunas de las especificaciones de servicios de mayor nivel, como WS-Security, ya están en el periodo "de facto" en el proceso de estandarización. Las empresas siguen proponiendo nuevas especificaciones como añadidos a la plataforma de servicios Web y la industria en su conjunto necesitará acordar cuáles adoptar. Esas especificaciones necesitarán a continuación ser estandarizadas.

En tercer lugar, los kits de herramientas y marcos de trabajo seguirán mejorando. Además de servicios de más alto nivel como la seguridad y los objetos adjuntos, se añadirá soporte para protocolos de transporte alternativos como SMTP o TCP. De modo más importante, los modelos de programación migrarán desde los servicios de tipo RPC hacia servicios centrados en documentos, para promover un acoplamiento débil. Todos estos cambios ocurrirán en paralelo, mientras los desarrolladores continúan desarrollando e implantando sistemas basados en servicios Web.

Avances de futuro

Llegados a este punto, estaremos preguntándonos cómo podemos utilizar los servicios Web cuando la plataforma todavía está evolucionando. Las herramientas y marcos de trabajo de los servicios Web actuales proporcionan suficiente funcionalidad básica para desarrollar interesantes aplicaciones distribuidas que envían mensajes SOAP sobre HTTP. Algunos servicios de mayor nivel como WS-Security están empezando a cuajar con el soporte de diversas herramientas nuevas como el kit Web Services Development Kit. Otros servicios están todavía en fase de desarrollo preliminar a medida que las especificaciones se van revisando y las primeras implementaciones exponen áreas en las que las especificaciones necesitan solidificarse. Mientras tanto, podemos apoyarnos en mecanismos HTTP tradicionales para implementar seguridad y demás características.

Si queremos desarrollar servicios Web utilizando herramientas de Microsoft, tenemos varias opciones. Si todavía estamos utilizando Visual Studio 6.0 o algún otro entorno de desarrollo que no soporta el desarrollo de código gestionado, podemos crear y consumir servicios Web utilizando el kit de herramientas SOAP Toolkit. Si estamos utilizando .NET, podemos focalizarnos en los métodos Web de ASP.NET (a esto hace referencia la mayor parte de la documentación de .NET sobre los servicios Web). En cualquier caso, podemos aprender tanto como queramos sobre cómo funcionan los protocolos de mensajería y metadatos de los servicios Web. Cuanto más comprendamos la fontanería, más fácil será desarrollar nuestros propios servicios y utilizar servicios desarrollados por los demás.

También podemos experimentar con las nuevas especificaciones. La versión preliminar del kit Microsoft WSDK Technology Preview proporciona un soporte preliminar para las especificaciones WS-Security, WS-Routing y DIME. Podemos también implementar especificaciones por nosotros mismos, tanto utilizando extensiones sobre uno de los marcos de trabajo o kits de herramientas (por ejemplo, SoapExtensions en ASP.NET), como crear nuestra propia pila SOAP utilizando XML plano y las APIs HTTP. Esta opción no es para todo el mundo, pero si tenemos tiempo y recursos, obtendremos pronto una avanzada funcionalidad. Además, contribuiremos al desarrollo de la plataforma. El entendimiento colectivo de SOAP Y WSDL se mejoró sustancialmente gracias al intento de implementación de sistemas basados en ambos estándares por parte de múltiples usuarios. Cuanto más estrechamente trabajen los usuarios con las nuevas especificaciones, mejor resultará la plataforma de servicios Web global.

También os pongo el enlace aquí