Conocernos

Mary Kirtland
Microsoft Corporation

3 de enero de 2001

Bienvenido a At Your Service, una nueva columna dedicada a los servicios web.

Los servicios web proporcionan información y servicios a las aplicaciones a través de interfaces de programación bien definidas basadas en protocolos estándar de Internet. Son una parte clave de Microsoft .NET. Naturalmente, en MSDN pensamos que deberíamos entender cómo compilarlos. No solo cómo insertar los botones en Visual Studio, sino cómo crear servicios web escalables, de alta disponibilidad, seguros y confiables.

Nuestro equipo ha obtenido una valiosa experiencia en la creación de aplicaciones web como Duwamish Online. ¿Qué hay de diferente en la creación de servicios web? ¿Qué problemas se ejecutan cuando otros desarrolladores quieren usar los servicios web en sus aplicaciones: aplicaciones hospedadas en diferentes sistemas operativos, escritas en distintos lenguajes y usando diferentes implementaciones de especificaciones clave, como SOAP?

Creemos que la única manera de averiguar es crear algunos servicios nosotros mismos. Por lo tanto, en los próximos meses, el equipo de instrucciones de servicios web compilará, implementará y operará algunos servicios web de ejemplo. Nuestro objetivo: ilustrar los problemas que debe tener en cuenta al diseñar, implementar, implementar y operar sus propios servicios web. (También veremos cómo consumir servicios web). Esperamos publicar un servicio web cada tres meses.

Tres meses es mucho tiempo para hacer que espere información nueva sin embargo. Por lo tanto, en la gran tradición del Diario Duwamish, usaremos esta columna para seguir cada proyecto de ejemplo desde la concepción a través del diseño, la implementación y la implementación. Al menos una vez cada dos semanas, publicaremos una entrada de diario para que puedas seguir con nosotros. A medida que completamos cada proyecto, publicaremos nuestras especificaciones, orígenes y otros artefactos de proyecto aquí en MSDN. Y siempre podrá acceder a toda esta información desde nuestro nuevo Centro para desarrolladores de servicios web.

Conocer al equipo

El equipo de orientación de servicios web consta actualmente de seis personas:

• Yo, Mary Kirtland, soy el jefe de cocina y cuello de botella —quiero decir, arquitecto y gerente de programas— para el equipo. Hago la mayoría de todo, pero código, prueba o opera nuestros servicios de ejemplo. Algunos de ustedes pueden conocerme de mis días como gerente de programas con el equipo OLE/COM/DCOM/MTS/COM+/whatever-you-want-to-call-it. Entonces desapareció en el cono de silencio que rodea a .NET. Hace aproximadamente un año, me di cuenta de que disfruto escribiendo sobre cómo usar tecnologías para crear aplicaciones mucho más de lo que disfruto de la creación de las propias tecnologías. Así que en abril, me mudé a MSDN para trabajar en lo que se ha convertido en el equipo de orientación de servicios web. Gran parte de mi tiempo se dedica a escribir esta columna y contenido para la página de recursos de servicios web. El resto se dedica a mantener actualizadas las especificaciones del proyecto y mantener un seguimiento de las nuevas tecnologías que queremos cubrir en el camino.
• Matt Powell y Scott Seely conforman nuestro equipo de desarrollo. Matt se unió al equipo en octubre del soporte técnico para desarrolladores. Matt escribió el agente de escucha de ISAPI en el kit de herramientas SOAP para Visual Studio 6.0, coautoría ejecutando Microsoft Information Server 4.0 para Microsoft Press, y ha escrito varios artículos para MSDN Magazine y sus predecesores, MSJ y MIND.
  Scott se unió a Microsoft y a nuestro equipo en diciembre después de pasar los últimos cinco años en el mundo real creando aplicaciones reales con productos de Microsoft. En su copioso tiempo libre, ha escrito artículos para el Diario para desarrolladores de Windows , así como un libro titulado Programación de Shell de Windows. Cuando no trabaja en nuestro servicio de ejemplo, está trabajando en un libro sobre SOAP.
  Puede esperar ver a Matt y Scott escribiendo artículos sobre el lado de desarrollo de las cosas en los meses que van a venir.
• Nuestro equipo de pruebas consta de Jan McCollum y Jim Francisco. Jan se unió a nosotros en octubre como responsable de pruebas y ha sido difícil trabajar con un plan de prueba para nuestro primer proyecto. Jim se unió a nosotros en diciembre y está trabajando en pruebas unitarias y automatización de pruebas. Jim ha trabajado en el equipo de prueba de Redes de Windows 98 y en el equipo de prueba de compilación y versión de Microsoft Host Integration Server. Vino a nuestro equipo después de un período en el mundo dot-com desarrollando herramientas de implementación y administración para aplicaciones web de n niveles. Intentaremos que escriban algunos artículos sobre la prueba de servicios web cuando estemos un poco más lejos.
• Bronwyn Calsyn es nuestro gerente de operaciones. Bronwyn comenzó en noviembre y ha estado ocupado tratando de averiguar qué equipo necesitamos para implementar nuestros servicios de ejemplo en Internet, junto con los procedimientos de operaciones que necesitamos para mantener las cosas funcionando sin problemas. También intentaremos que escriba algunos artículos sobre la implementación y las operaciones.

Presentación del servicio Favoritos

Nuestro primer proyecto es el servicio Favoritos. Como usuarios avides de la Web, reconocemos que uno de los problemas a los que se enfrentan los usuarios finales está localizando páginas que han visitado anteriormente, especialmente en sitios dinámicos como MSDN Online, o sitios de noticias en los que los artículos no son accesibles desde la página principal durante más de unos días. Aunque puede usar favoritos del explorador para realizar un seguimiento de las páginas favoritas, los favoritos del explorador son locales para un equipo específico. ¿Pero qué ocurre si usa varias máquinas o dispositivos? ¿No sería agradable si los favoritos podrían almacenarse en un servidor en algún lugar, fácilmente accesible desde cualquier máquina que haya usado?

Esto es exactamente lo que hace el servicio Favoritos. Permite a los sitios web almacenar vínculos a las páginas web favoritas de un usuario final. Ahora, podría pensar que esto no suena como un servicio muy complicado. Y desde la perspectiva de la lógica de negocios, no lo es. Esto significa que no tendremos que dedicar mucho tiempo a explicar la lógica de negocios y no tendrá mucho código específico de la aplicación para navegar por para encontrar técnicas que puede usar en sus propios servicios web. Pero hemos encontrado una serie de problemas interesantes con el servicio: problemas en los que muchos otros desarrolladores a los que hablamos también se ejecutan.

Nuestras primeras columnas se centrarán en los problemas que hemos encontrado durante la fase de diseño del proyecto. Algunos de los temas que estamos considerando son:

• Protección de la privacidad del usuario. ¿Debe cualquier aplicación del mundo poder consultar o editar los favoritos de cada usuario final, independientemente de la aplicación que guarde los favoritos en primer lugar?
• de Microsoft. Si cada aplicación no puede acceder a todos los favoritos del usuario final, ¿cómo se controla el acceso al servicio? ¿Deberíamos cobrar dinero por el servicio? ¿Qué modelos de negocio tienen sentido?
• Autenticación y autorización. Si vamos a restringir el acceso al servicio, ¿cómo autenticamos las aplicaciones cliente y decidimos qué están autorizados para hacer? ¿Cómo identificamos a los usuarios finales de todos modos?
• Estimación de los requisitos de rendimiento. ¿Cómo se sabe a qué tipo de carga se somete nuestro servicio? ¿Podemos usar los mismos métodos que usaríamos para calcular la carga en un sitio web? ¿Cómo determinamos qué tipo de tiempos de respuesta y disponibilidad demandarán nuestros clientes?
• Requisitos de licencia de desarrollo, pruebas y operaciones. Si estamos restringiendo el acceso al servicio, quizás cobrando dinero en función del uso, ¿cómo prueban los desarrolladores y evaluadores de aplicaciones cliente que dependen de nuestro servicio? ¿Cómo pueden evitar afectar a los almacenes de datos de producción? ¿Qué tipos de herramientas necesitan los empleados de pruebas y operaciones de nuestros clientes para ayudar a solucionar si hay un problema en sus aplicaciones o en nuestro servicio? ¿Qué tipo de documentación se debe proporcionar?
• Globalización. ¿Qué debemos hacer para garantizar que las aplicaciones cliente de todo el mundo puedan usar nuestro servicio web?
• Capacidad de administración. ¿Qué tipo de información necesita nuestro personal de operaciones para administrar nuestro servicio web? ¿Cómo recopilamos esa información y la presentamos a las herramientas de administración?

Si hay otros temas que le gustaría ver cubiertos, envíenos un correo electrónico a wsgmsdn@microsoft.com. Tenga en cuenta que en este momento no podemos responder a través de los comentarios del usuario en esta página. Sin embargo, leemos los comentarios con regularidad. Si podemos averiguar lo que sus comentarios tienen que ver con nuestro contenido, veremos lo que podemos hacer para solucionar el problema en una columna futura.

La próxima semana veremos los problemas que encontramos al definir la visión del proyecto de Servicio favoritos. ¡Vete entonces!