Extractado de La Guía de Arquitectura Versión 2.0a del grupo de Patterns and Practices de Microsoft.

Disponibilidad define la proporción del tiempo que el sistema es funcional y trabaja. Puede ser medido como un porcentaje del tiempo total en que el sistema estuvo caído en un periodo predefinido. La disponibilidad puede verse afectada por errores del sistema, problemas de infraestructura, ataques o carga del sistema.

Integridad Conceptual define la consistencia y coherencia del diseño total. Esto incluye la forma en que los componentes o módulos han sido diseñados, así como factores como el estilo de codificación y la nomenclatura de las variables.

Flexibilidad es la habilidad del sistema para adaptarse a ambientes y situaciones variables y para soportar cambios en políticas de negocios y reglas de negocio. Un sistema flexible es uno que es fácil de reconfigurar o que se adapta en respuesta a los diferentes requerimientos de usuarios y del sistema.

Interoperabilidad es la habilidad de que diversos componentes de un sistema diferentes sistemas funcionen correctamente al intercambiar información, comúnmente por medio de servicios. Un sistema interoperable hace fácil intercambiar y usar información interna y externamente.

Capacidad de mantenimiento es la habilidad de un sistema para permitir cambios en sus componentes, servicios, características e interfaces en la medida en que dichos cambios son requeridos cuando se adiciona o cambia la funcionalidad, se corrigen errores o se suplen nuevos requerimientos de negocios.

Capacidad de Administración define que tan fácil es gestionar la aplicación, usualmente a través de una instrumentación suficiente y adecuada que se expone en un sistema de monitoreo para efectos mejoramiento del rendimiento e identificación de errores.

Rendimiento es un indicador de la capacidad de respuesta del sistema para ejecutar una acción dentro de un intervalo de tiempo dado. Puede ser medida en términos de latencia o de respuesta. Latencia es el tiempo que tarda en responder a un evento, respuesta en es el numero de eventos que tiene lugar en una cantidad dada de tiempo.

Confiabilidad es la habilidad de un sistema para mantener operacional en el tiempo. La confiabilidad se mide como la probabilidad de que un sistema no falle en ejecutar la función para la que fue construido dentro de un periodo especifico de tiempo.

Capacidad de Re-Uso define la capacidad de un componente y un subsistema para ser usado por otras aplicaciones en otros escenarios. La capacidad de re-uso minimiza la duplicación de componentes así como el tiempo de implementación.

Escalabilidad es la habilidad de un sistema para funcionar bien cuando se presentan cambios en la demanda o en la carga del mismo. Típicamente el sistema será capaz de extenderse a un número mayor o más poderoso de servidores al incrementarse la demanda o la carga.

Seguridad define la forma en que el sistema es protegido de perder o suministrar información y la posibilidad de éxito de un ataque. Un sistema seguro trata de proteger sus actives y previene la modificación de información de fuentes no autorizadas.

Capacidad de Soporte define que tan fácil es para los operadores, desarrolladores, y usuarios entender y usar la aplicación así como que tan fácil es resolver los errores que se presentan cuando la aplicación falla.

Capacidad de Pruebas es una medida de que tan fácil es crear un criterio de pruebas para el sistema y sus componentes y como ejecutar estos test en un orden que permita determinar si el criterio se cumplió. Una buena capacidad de pruebas hace más común que las falas en el sistema puedan ser aisladas de una forma rápida y efectiva.

Usabilidad define que tan bien la aplicación cumple con los requerimientos de los usuarios y los consumidores al ser intuitiva, fácil de localizar y globalizar, y capaz de proveer acceso correcto para usuarios con discapacidad así como una experiencia general Buena para el usuario.

Juan Carlos Pelaez
Arquitecto de Sofware.

Keywords: 3Metas, Juan Pelaez, Arquitectura, Emprendimiento, Desarrollo de Software, Aplicaciones Distribuidas, Juan Carlos Pelaez, Colombia, Desarrollo de Software, Soluciones, Silverlight, Sharepoint, WCF, WPF, Desarrollo de Aplicaciones Web, Desarrollo de Aplicaciones para Intranet, Web 2.0, Nuevos Medios.

Publicado en : www.juanpelaez.com

Publicidad: Necesita Arquitectos en soluciones basadas en plataforma Microsoft? 3Metas Corp tiene un grupo de especialistas que pueden apoyar sus procesos de diseño, construcción e implementación de soluciones.  Contáctenos al correo electrónico sales@3metas.com

Extractado de La Guía de Arquitectura Versión 2.0a del grupo de Patterns and Practices de Microsoft. Para los que nos gusta en la lengua de cervantes:

La arquitectura orientada a servicios permite que la funcionalidad de la aplicación se exponga y consuma como un conjunto de servicios. Los servicios usan una forma estándar de interacción que les permiten ser invocados, publicados y descubiertos. Los servicios SOA están enfocados en proveer un esquema (schema) y una interacción basada en mensajes con una aplicación. Los servicios SOA proveen interfaces con alcance de aplicación en vez de interfaces del nivel de componente u objeto. En otras palabras un servicio SOA no debe ser tratado como un servicio proveído por un componente.

El estilo SOA tiene las siguientes características que lo identifican:

• La interacción con los servicios es desacoplada.

• Puede involucrar procesos de negocios que se convierten en servicios interoperables.

• Clientes y otros servicios pueden accede a servicios locales que se ejecutan en el mismo nivel.

• Clientes y otros servicios acceden a servicios remotos sobre una red que los conecta.

• Estos servicios pueden usar un rango de protocolos y formatos de datos para comunicar información.

Principios Fundamentales.

Los principios fundamentales de la arquitectura estilo SOA son:

• Los servicios son autónomos. Cada servicio SOA es mantenido, desarrollado, instalado y versionado de forma independiente.

• Los servicios son distribuibles. Los servicios SOA pueden ser localizados en cualquier parte sobre la red, local o remotamente en tanto que la red soporte los protocolos de comunicación requeridos.

• Los servicios son desacoplados. Cada servicio SOA es independiente de los otros y puede ser reemplazado o actualizado sin romper con las aplicaciones que lo consumen en tanto que la interface siga siendo compatible.

• Los servicios comparten esquemas y contratos no clases. Los servicios SOA comparten contraltos y esquemas cuando se comunican, no clases internas.

• La compatibilidad está basada en políticas. Política en este caso significa la definición de características como transporte, protocolo y seguridad.

Beneficios

Los mayores beneficios del estilo de arquitectura SOA son:

• Alineación con el Dominio. El re-uso de servicios comunes con interfaces estándar incrementa las oportunidades de negocios y reduce costos.

• Abstracción. Los servicios son autónomos y se accede a ellos a través de un contrato formal lo que provee desacople y abstracción.

• Capacidad de Descubrimiento. Los servicios pueden exponer descripciones que permiten a otras aplicaciones y servicios localizarlos y determinar de forma automática la interfaz.

Ejemplos

Ejemplos comunes de aplicaciones orientadas a servicios incluyen:

• Sistemas que comparten información médica.(Harvard Medical School)

• Sistemas de reservas (Starwood Hotels and Resorts)

• Sistemas de WorkFlow. (State Children’s Health Insurance Program)

Juan Carlos Pelaez
Arquitecto de Sofware.

Keywords: 3Metas, Juan Pelaez, Arquitectura, Emprendimiento, Desarrollo de Software, Aplicaciones Distribuidas, Juan Carlos Pelaez, Colombia, Desarrollo de Software, Soluciones, Silverlight, Sharepoint, WCF, WPF, Desarrollo de Aplicaciones Web, Desarrollo de Aplicaciones para Intranet, Web 2.0, Nuevos Medios.

Publicado en : www.juanpelaez.com

Publicidad: Necesita Arquitectos en soluciones basadas en plataforma Microsoft? 3Metas Corp tiene un grupo de especialistas que pueden apoyar sus procesos de diseño, construcción e implementación de soluciones.  Contáctenos al correo electrónico sales@3metas.com

Extractado de La Guía de Arquitectura Versión 2.0a del grupo de Patterns and Practices de Microsoft. Para los que nos gusta en la lengua de cervantes:

La arquitectura basada en capas se enfoca en la distribución de roles y responsabilidades de forma jerárquica proveyendo una forma muy efectiva de separación de responsabilidades. El rol indica el modo y tipo de interacción con otras capas, y la responsabilidad indica la funcionalidad que está siendo desarrollada.

Por ejemplo, una aplicación web típica está compuesta por una capa de presentación (funcionalidad relacionada con la interfaz de usuario), una capa de negocios (procesamiento de reglas de negocios) y una capa de datos (funcionalidad relacionada con el acceso a datos).

El estilo de arquitectura basado en capas se identifica por las siguientes características:

• Describe la descomposición de servicios de forma que la mayoría de la interacción ocurre solamente entre capas vecinas.

• Las capas de una aplicación pueden residir en la misma maquina física (misma capa) o puede estar distribuido sobre diferentes computadores (n-capas).

• Los componentes de cada capa se comunican con otros componentes en otras capas a través de interfaces muy bien definidas.

• Este modelo ha sido descrito como una “pirámide invertida de re-uso” donde cada capa agrega responsabilidad y abstracción a la capa directamente sobre ella.

Principios fundamentales

Los principios comunes que se aplican cuando se diseña para usar este estilo de arquitectura incluyen:

• Abstracción. La arquitectura basada en capas abstrae la vista del modelo como un todo mientras que provee suficiente detalle para entender las relaciones entre capas.

• Encapsulamiento. El diseño no hace asunciones acerca de tipos de datos, métodos, propiedades o implementación.

• Funcionalidad claramente definida. El diseño claramente define la separación entre la funcionalidad de cada capa. Capas superiores como la capa de presentación envía comandos a las capas inferiores como la capa de negocios y la capa de datos y los datos fluyen hacia y desde las capas en cualquier sentido.

• Alta cohesion. Cada capa contiene funcionalidad directamente relacionas con la tarea de dicha capa.

• Reutilizable. Las capas inferiores no tienen ninguna dependencia con las capas superiores, permitiéndoles ser reutilizables en otros escenarios.

• Desacople. La comunicacion entre las capas está basada en la abstracción lo que provee un desacople entre las capas.

Beneficios

Los principales beneficios del estilo de arquitectura basado en capas son:

• Abstracción. Las capas permiten cambios que se realicen en un nivel abstracto. Usted puede incrementar o disminuir el nivel de abstracción usado en cada capa de la “pila” jerárquica.

• Aislamiento. El estilo de arquitectura de capas permite asilar los cambios en tecnologías a ciertas capas para reducir el impacto en el sistema total.

• Rendimiento. Distribuir las capas entre múltiples sistemas (físicos) puede incrementar la escalabilidad, la tolerancia a fallos y el rendimiento.

• Mejoras en Pruebas. La capacidad de realizar pruebas se beneficia de tener una interfaces bien definidas para cada capa así como de la habilidad para cambiar a diferentes implementaciones de las interfaces de cada capa.

• Independencia. El estilo de arquitectura basado en capas el requerimiento de considerar el hardware y los problemas de instalación así como las dependencias de interfaces externas.

Ejemplos

Algunos tipos comunes de aplicaciones por capas incluyen:

• Aplicaciones de línea de negocios (LOB), como contabilidad, y sistemas de gestión de clientes.

• Aplicaciones web Corporativas y sitios Web

• Aplicaciones corporativas de escritorio o clientes inteligentes con servidores centralizados de aplicación con lógica de negocios.

Los siguientes son algunas variaciones del estilo de arquitectura basado en capas:

• Capas estrictas (Strict layering). Cada capa solo puede invocar a la capa directamente debajo de a ella.

• Saltos de Capas (Layer skipping). Las capas pueden invocar otras capas más profundas que las que están directamente debajo de ellas. Esto puede incrementar el rendimiento pero impacta la portabilidad.

• Capa de Caja Negra (Black-box layering). Los limites de las capas y sus dependencias esta definidas de forma estricta usando interfaces, lo que soporta extensiones en run-time, intercepción y mejora la capacidad de realiza pruebas.

• Capa de Caja Blanca (White-box layering). Clases que colaboran entre los límites de las capas y están altamente acopladas.

Arquitectura de N-Capas / 3-Capas

Este estilo de despliegue arquitectónico describe la separación de la funcionalidad en segmentos separados de forma muy parecida al estilo de capas, pero en el cual cada segmento está localizado en un computador físicamente separado. Este estilo ha evolucionado desde la aproximación basada en componentes generalmente usando métodos específicos de comunicación asociados a una plataforma en vez de la aproximación basada en mensajes.

Principios Fundamentales.

Los siguientes son los principios fundamentales del estilo de arquitectura basado en N-capas/3-capas:

• Es un estilo para definir el despliegue de las capas en una instalación.

• La arquitectura de N-capas está caracterizada por la descomposición functional de la aplicación, los componentes de servicio y su instalación distribuida. Mejorando la escalabilidad, disponibilidad, administración, y utilización de recursos.

• Cada capa es completamente independiente de las otras capas, excepto aquella que esta inmediatamente debajo de ella. La capa n solo necesita saber cómo manejar una solicitud de la capa n+1, como hacer la solicitud a la capa n-1 (si existe) y cómo manejar el resultado de la petición.

• La arquitectura de N-capas tiene al menos tres capas separadas o partes, cada una de ellas con su responsabilidad y está localizada en diferentes servidores.

• Una capa es desplegada en un nivel específico si más de un servicio o aplicación está expuesto por esa capa.

Beneficios.

Los principales beneficios del estilo de arquitectura de N-capas/3-capas son:

• Mejoras en las posibilidades de mantenimiento. Debido a que cada capa es independiente de la otra los cambios o actualizaciones pueden ser realizados sin afectar la aplicación como un todo.

• Escalabilidad. Como las capas están basadas en diferentes maquinas, el escalamiento de la aplicación hacia afuera es razonablemente sencillo.

• Flexibilidad. Como cada capa puede ser manejada y escalada de forma independiente, la flexibilidad se incrementa.

• Disponibilidad. Las aplicaciones pueden aprovechar la arquitectura modular de los sistemas habilitados usado componentes que escalan fácilmente lo que incrementa la disponibilidad.

Ejemplos.

Algunos ejemplos del estilo de arquitectura de N-capas/3-capas son:

• Una aplicación Web Financiera donde la seguridad es importante y la capa de negocios necesita estar instalada detrás de un Firewall, lo que obliga la instalación de la capa de presentación en una capa separada del perímetro.

• Una aplicación de cliente rico conectada, donde la capa de presentación esta en las maquinas cliente y las capas de negocios y datos están instaladas en el servidor.

Juan Carlos Pelaez
Arquitecto de Sofware.

Keywords: 3Metas, Juan Pelaez, Arquitectura, Emprendimiento, Desarrollo de Software, Aplicaciones Distribuidas, Juan Carlos Pelaez, Colombia, Desarrollo de Software, Soluciones, Silverlight, Sharepoint, WCF, WPF, Desarrollo de Aplicaciones Web, Desarrollo de Aplicaciones para Intranet, Web 2.0, Nuevos Medios.

Publicado en : www.juanpelaez.com

Publicidad: Necesita Arquitectos en soluciones basadas en plataforma Microsoft? 3Metas Corp tiene un grupo de especialistas que pueden apoyar sus procesos de diseño, construcción e implementación de soluciones.  Contáctenos al correo electrónico sales@3metas.com

Extractado de La Guía de Arquitectura Versión 2.0a del grupo de Patterns and Practices de Microsoft. Para los que nos gusta en la lengua de cervantes:

ARQUITECTURA BASADA EN COMPONENTES.

Una arquitectura basada en componentes describe una aproximación de ingeniería de software al diseño y desarrollo de un sistema. Esta arquitectura se enfoca en la descomposición del diseño en componentes funcionales o lógicos que expongan interfaces de comunicación bien definidas. Esto provee un nivel de abstracción mayor que los principios de orientación por objetos y no se enfoca en asuntos específicos de los objetos como los protocolos de comunicación y la forma como se comparte el estado.

El estilo de arquitectura basado en componentes tiene las siguientes características:

• Es un estilo de diseño para aplicaciones compuestas de componentes individuales.

• Pone énfasis en la descomposición del sistema en componentes lógicos o funcionales que tienen interfaces bien definidas.

• Define una aproximación de diseño que usa componentes discretos, los que se comunican a través de interfaces que contienen métodos, eventos y propiedades.

Principios Fundamentales

Un componente es un objeto de software específicamente diseñado para cumplir con cierto propósito. Los principios fundamentales cuando se diseña un componente es que estos deben ser:

• Reusable. Los componentes son usualmente diseñados para ser utilizados en escenarios diferentes por diferentes aplicaciones, sin embargo, algunos componentes pueden ser diseñados para tareas específicas.

• Sin contexto especifico. Los componentes son diseñados para operar en diferentes ambientes y contextos. Información específica como el estado de los datos deben ser pasadas al componente en vez de incluirlos o permitir al componente acceder a ellos.

• Extensible. Un componente puede ser extendido desde un componente existente para crear un nuevo comportamiento.

• Encapsulado. Los componentes exponen interfaces que permiten al programa usar su funcionalidad. Sin revelar detalles internos, detalles del proceso o estado.

• Independiente. Los Componentes están diseñados para tener una dependencia mínima de otros componentes. Por lo tanto los componentes pueden ser instalados en el ambiente adecuado sin afectar otros componentes o sistemas.

Beneficios

Los siguientes son los principales beneficios del estilo de arquitectura basado en componentes:

• Facilidad de Instalación. Cuando una nueva versión esté disponible, usted podrá reemplazar la versión existente sin impacto en otros componentes o el sistema como un todo.

• Costos reducidos. El uso de componentes de terceros permite distribuir el costo del desarrollo y del mantenimiento.

• Facilidad de desarrollo. Los componentes implementan un interface bien definida para proveer la funcionalidad definida permitiendo el desarrollo sin impactar otras partes del sistema.

• Reusable. El uso de componentes reutilizables significa que ellos pueden ser usados para distribuir el desarrollo y el mantenimiento entre múltiples aplicaciones y sistemas.

• Mitigación de complejidad técnica. Los componentes mitigan la complejidad por medio del uso de contenedores de componentes y sus servicios. Ejemplos de servicios de componentes incluyen activación de componentes, gestión de la vida de los componentes, gestión de colas de mensajes para métodos del componente y transacciones.

Ejemplos

Tipos comunes de componentes usados en aplicaciones incluyen:

• Componentes de interfaz de usuario, como grillas, botones, etc., generalmente conocidos como “controles”.

• Componentes de ayuda que exponen un conjunto específico de funciones usados por otros componentes.

• Componentes que se no se usan con mucha frecuencia o son intensivos en recursos y deben ser actividades usando una aproximación de solo en el momento justo (Just in Time (JIT)). Estos son comunes en escenarios de componentes distribuidos o en componentes remotos.

• Componentes encolados, aquellos cuyos métodos pueden ser ejecutados de forma asíncrona usando colas de mensajes del tipo almacenamiento, entrega.

Juan Carlos Pelaez
Arquitecto de Sofware.

Keywords: 3Metas, Juan Pelaez, Arquitectura, Emprendimiento, Desarrollo de Software, Aplicaciones Distribuidas.

Publicado en : www.juanpelaez.com

Publicidad: Necesita Arquitectos en soluciones basadas en plataforma Microsoft? 3Metas Corp tiene un grupo de especialistas que pueden apoyar sus procesos de diseño, construcción e implementación de soluciones.  Contáctenos al correo electrónico sales at 3metas.com

Me gusta mucho el conjunto de guías de arquitectura de soluciones .Net del grupo de Patterns and Practices de Microsoft. El documento principal es La Guia de Arquitectura Version 2.0a, una de las principales razones por las que me gusta esta guía es por la definición de cómo encajan los diferentes elementos o tipos de arquitecturas juntas en un esquema que es sencillo pero muy elegante y que se resume en este gráfico:

Al segmentar las aplicaciones por tipos (más o menos obvio no?), y separar los conceptos como estilos de arquitectura, atributos de calidad, tendencias etc., se obtiene una forma más sencilla de explicar porque se hace una aplicación de una forma y no de otra, lo que en general podemos decir que es la arquitectura. Una de las secciones más interesante tiene que ver con los estilos de arquitectura (sobre el que profundizare más adelante) ya que establece las diferencias entre elementos que son un poco confusos al seleccionar que tipo de aplicación se quiere construir y nos permite explicar de una manera clara al cliente por que se tomaron estas decisiones de diseño.

Si usted alguna vez se ha preguntado como una arquitectura SOA se integra con una arquitectura por componentes y con el paradigma de Orientación por Objetos este es definitivamente un documento que debería leer.

Juan Peláez

Arquitecto de Software

Publicado en: www.juanpelaez.com

Keywords: Juan Pelaez, Arquitectura de Software, 3Metas, Patterns and Practices, Microsoft, .Net.

Publicidad: Necesita ayuda en la arquitectura de su aplicación .Net?, no está seguro si su desarrollo cumplirá con los requerimientos de escalabilidad, seguridad, requerimientos de negocios o expectativas de los usuarios?, Quiere validar si sus desarrolladores o contratistas siguen las mejores prácticas para el desarrollo de aplicaciones? Los servicios de consultoría en Arquitectura de Soluciones de 3Metas seguramente serán un de las mejores alternativas. Contáctenos al correo electrónico contacto@3Metas.com

CDN (Content Distribution Network) es un sistema de distribución de archivos basado en ubicaciones geográficas muy útil cuando se construyen sistemas de alta disponibilidad. Ya hice un post del tema hace algunos días aquí.

Y también hace poco escribí sobre el sistema de hosting que uso que es basado en Cloud Computing, aquí.

Hace poco estos dos servicios se han integrado para ofrecer un mejor paquete y ahora es posible por muy poco dinero y solo con una tarjeta de crédito tener en cuestión de horas un sistema de hosting por demanda integrado con la red de distribución de contenido. Todo parece muy sencillo: creo una carpeta en el sistema del sitio y subo mis archivos, marco la carpeta como publica y listo, ahora esos archivos se distribuyen usando una CDN de las más usadas en el mundo. Cuando no lo quiero mas entonces solo quito la marca de folder publico y listo, ya no se actualiza el archivo en el cache de la CDN.

Supongamos que creamos un sitio de distribución de videos del tipo YouTube o de música como sonidolocal.com, eso son miles de canciones o archivos de gran tamaño, un monton de dinero para gastar en ancho de banda, almacenamiento, etc, con estos sistemas lo que hago es pagar por uso, dejar que ellos corran con los costos de infraestructura y demás y puedo crecer el servicio a la medida que mi sitio crezca.

Amazon ofrece un servicio parecido llamado S3 que parece funcionar muy bien, pero en el cual hay que pagar por el almacenamiento y aparte por el uso de la CDN, asi que el servicio de Mosso en ese aspecto parece mejor.

Cuando empecé mi primera compañía en internet en el año 2000, el primer gasto era de 550 dólares mensuales por un servidor dedicado en DellHost, una cifra absurda para una empresa que había facturado 0 dólares el día 1, pero necesario para poder poner algo en la red. Estos nuevos sistemas de costos y de pago por uso hacen que todo cambie, no solo para las nuevas compañías, también para nuestros clientes.

Juan Pelaez

Arquitecto de Software.

Keywords: Mosso, CDN, Juan Pelaez, Juan Carlos Pelaez, Software como Servicio, SaaS, Infraestructura como Servicio, Hosting as a Service, Hosting como Servicio, Redes de Distribucion de Contenido.

Acabo de trasladar el sitio www.juanpelaez.com y otros sitios asociados a un nuevo proveedor de hosting, estuve un par de años con el anterior proveedor pero de repente decidieron migrar sus servidores de correo a un servidor Linux (sin notificar a los usuarios), como resultado de la migración estuve desde el 29 de junio hasta el 9 de Julio sin correo, llame en varias ocasiones a Servicio al Cliente, pero nunca pude obtener una solución, así que solo me quedo cambiarme de proveedor, curiosamente el proceso de retirarme del servicio si fue muy rápido, sin embargo no pareció importarle a nadie las razones por las que me estaba cambiando (nadie me pregunto nada).

Hosting

Pues bien me cambie a mosso (the hosting Cloud) un nuevo concepto de hosting realmente novedoso, no preguntan por servidores dedicados, compartidos, virtual servers ni nada de eso, es puro software como servicio (SaaS) o incluso servicios como servicios. (SsaaSs), así que me inscribo en el sistema, me crean una consola de gestión de mis sitios en 5 minutos y estoy listo para empezar a distribuir servicios de hosting:

· Puedo crear mis clientes

· Luego puedo crear uno o muchos sitios para cada cliente, incluidas cuentas de correo ilimitadas.

· Puedo establecer si a este cliente se le va a facturar (debería!) y el sistema genera las facturas por mí para que yo se las envíe a mis clientes.

· Puedo establecer si los sitios de mis clientes son en Windows (IIS7,.Net 3.5) o Php, Linux, incluso RubyonRails.

· Tengo buenos reportes de uso, de facturación, etc.

· Tengo un buen servicio de soporte por Mail, LiveChat y Telefono, 7x24.

· Todo esto desde la consola Web de administración del sistema.

· tengo 500GB de ancho de banda, 50GB de espacio en Disco y 3 Millones de peticiones web por Mes.

Si la anterior lista no le impresiona piense en esto, antes tenía un servidor Windows, si alguna vez quería montar una aplicación de pruebas en Linux con Apache, necesitaba otro servidor de hosting, así que estaba realmente limitado a lo que estaba pagando: Un servidor Windows. Ahora no importa si alguna vez necesito un website en Apache Php o en Ruby on Rails simplemente lo tengo, es un cambio de paradigma importante en vez de preguntarme por hardware o Sistemas operativos me preguntan por la necesidad que tengo: Sitios Web.

Yo mismo migre los apuntadores de los DNS desde mi antiguo proveedor al nuevo, empecé el proceso de registro en este nuevo proveedor a las 3 de la tarde y a las 5pm ya tenía mi correo nuevamente arriba. Apenas termine de cargar los archivos me conecte con el servicio al cliente (10pm) y rápidamente configure mis aplicaciones (básicamente un blog de DASBlog), la gente parecía saber de su tema. Así que en menos de 12 horas ya tenía desde cero mis sitios corriendo en un nuevo servidor.  En teoría solo pago lo que consumo (con un mínimo de 100 dólares) pero parece un buen trato.

Por cierto este servicio es un emprendimiento nuevo de RackSpace que es la compañía mejor clasificada para servicios de hosting de acuerdo con las revisiones de webHost Magazine

Software as a Service

Este es un tema interesante (mas allá de mi cambio de dominio) por que se habla mucho de computación en la nube (Cloud Computing)  y hay muchos rumores y realidades que van desde alquiler de Exchange y SharePoint por parte de Microsoft hasta inversiones gigantes de Microsoft en infraestructura (3 datacenters nuevos en USA, el de Chicago el más grande de USA, etc) hasta nuevo servicios de publicación de aplicaciones corporativas en Internet que serán anunciados en las próximas conferencias de Desarrolladores. Así que empezar a ver este tipo de servicios es realmente un aviso de cómo será el futuro de internet y de la computación.

En el software as a Service (SaaS) un tema muy importante es el aprovisionamiento (Provisioning) del servicio, es un concepto interesante porque un servicio NECESITA ser escalable y eso solo es posible con sistemas automáticos, por ejemplo en este servicio de hosting todo pasa sin intervención de humanos, creo los sitios, creo las cuentas, facturo, etc., el sistema de aprovisionamiento es clave para el éxito del software que será rentado.  

Y claro ahora que tengo otras preocupaciones como el espacio que uso y demás empiezo a replantearme la forma como estoy usando otros servicios de la Nube, por ejemplo: a partir de ahora todas las fotos las publicare en flickr.com y solo colocares los apuntadores en mis posts, de pronto es un poco más de trabajo desde Windows Live Writer al momento de publicar, pero seguro vale la pena. Todos los archivos los estoy publicando en skydrive.live.com y todos los videos los voy a poner en Silverlight streaming, de esta forma ahorro montones en ancho de banda, y espacio.

Y claro el toque final es poner todos mis RSS a apuntar a través de feedBurner, para que los que se suscriban al blog no gasten mi precioso ancho de banda.

Juan Carlos Peláez
Arquitecto de Software

Keywords: Software as a Service, Cloud Computing, Hosting, Juan Peláez, Juan Carlos Peláez, Windows Live Services, Blog, DasBlog.

Desde hace algunos meses vengo participando en un Proyecto Grande para Dunkin Donuts en Estados Unidos, básicamente la construcción del sitio www.DunkinDonuts.com y otros sitios afiliados como www.myicedcoffee.com, estos sitios utilizan diferentes tecnologías como Flash, JavaScript, WebServices, Certificados Digitales, y otra lista de cosas que son interesantes de poner a trabajar juntas y que son probadas en todos los sistemas operativos y navegadores populares.

Estos sitios esperan tener cantidades masivas de visitantes todo el tiempo con picos muy altos en ciertas campanas publicitarias y días especiales, así que hay que enfrentar el problema de la alta disponibilidad en serio, y si se le agrega que se usan muchas películas de flash (corriendo contra servicios web) algunas de ellas muy pesadas, entonces se tiene una combinación un poco complicada.

En este sitio se han implementado diferentes soluciones como un cluster de BD, un Cluster de servidores de presentación, cada servidor con 4 Gigas de RAM y sistemas redundantes de acceso a datos, etc, incluso tarjetas de red dedicadas para la comunicaciones entre las maquinas, la salida a internet e incluso la que me permite conectarme para tareas de administración.

Sin embargo, una de las tecnologías más interesantes que hemos empleado tiene que ver con la Red de Distribución de Contenido (CDN por Content Distribution Network) que se ha implementado, aquí algunas líneas al respecto. (No es la única, muchas decisiones de arquitectura de la aplicación, de infraestructura y de negocios deben tomarse e implementarse correctamente para que un sitio realmente soporte un tráfico fuerte, empezando por tener una idea de cuánto trafico se estima tener).

Que es una CDN?

Una red de distribución de contenido es un montón de infraestructura generalmente distribuida por todo el mundo (al menos puntos claves para internet) que guardan copias locales de ciertos tipos de archivos para entregue a los usuarios que los solicitan usando ventajas geográficas (están más cerca). (Usted de verdad no creía que youtube tenía los discos duros más grandes del mundo o sí?). De esta forma cuando un usuario solicita (a través del browser) un video, canción, imagen, o incluso una de las películas de flash, esta le es enviada desde el servidor que se encuentra más cerca. Más referencias e información en ingles aquí

Como toda esa infraestructura es arrendada se obtienen importantes beneficios en costos de hardware y uso del ancho de banda de su proveedor de hosting, y para los usuarios la experiencia es muy buena porque siente que su sitio es mucho más rápido de lo que en realidad es.

Como se usa?

Una de las cosas realmente increíbles de esto es la forma como funciona desde la perspectiva del desarrollador (es decir la mía) (la otra cosa increíble es como selecciona quien en realidad está cerca, pero ese es otro tema), para mi es transparente la localización del archivo, es decir no me importa.

Por ejemplo:

Supongamos que tengo unas imágenes muy grandes que quiero que se suban a esta red CDN, en mi estructura de archivos están en una carpeta images y yo las referencio como src=”images/imagengrande1.jpg” bueno, al afiliarse a la red de distribución de contenido ellos le van a crear un apuntador para su dominio del tipo assets.midominio.com, así que ahora en vez de apuntar el scr de la imagen como antes usted pone scr=http://assets.midominio.com/images/imagengrade.jpg, la magia ocurre cuando al hacer la solicitud un usuario por primera vez, la CDN busca en su propia lista de archivos, como no la encuentra va hasta su servidor y se la manda al usuario, pero al mismo tiempo saca una copia y la almacenan en sus propios servidores, es decir que entre más personas visiten el sitio de diferentes partes del mundo o del país, mas rápido funciona al sacar copias del contenido al momento de distribuirlo.

Es decir, usted no sube nada a la red, ella sola se alimenta a medida que sus usuarios piden los archivos, y no hay problemas de crosssite scripting por que los archivos si están en su dominio, solo que en otras maquinas.

Esto genera dos problemas, ambos fáciles de solucionar y que bueno, por el beneficio puedo vivir con ellos.

1. Obviamente si hay un cambio en el archivo que está cargado en la red, de alguna forma hay que notificarlo para que se actualice el archivo, sino la red de CDN va a seguir enviando el archivo desactualizado. Sin embargo todas estas redes tienen una consola de administración donde usted puede ver reportes de uso, pero también puede solicitar que un archivo sea actualizado, es un proceso automatizado generalmente basado en colas pero que dependiendo del trafico del sitio puede tomar desde minutos hasta horas, así que procure evitar los cambios.

2. Como en el proceso de desarrollo muchas veces hay que cambiar cosas (no debería ser, pero así es), es mejor tener alguna forma de “prender y apagar” el servicio, asi que una buen opción es poner en el archivo de configuración la ruta que se va a usar o en el load del control o en una función de JS o en CSS donde se pueda hacer el cambio en un solo sitio y afecte todos los archivos que se están cambiando.

Para tener una?

Los proveedores de este servicio son Akamai, LimeLight Network (ya que estoy usando) (por cierto que Akamai demando a LimeLight por 45 millones de dólares, según ellos Limelight violo la licencia concedida por MIT para usar la tecnología que permite hacer la reconstrucción de los URL de los archivos que se usan en la CDN), así que solo hay que ir y suscribirse, pagar el servicio mensual y listo hay diversos servicios incluido el de tener televisión de HD por internet hospedada en la red.

Espero que esto le ayude a salvar algunas horas y a construir sitios de altísima disponibilidad.

Juan Carlos Peláez

Arquitecto de Software

Keywords: Arquitectura, CDN, Content delivery Network, Content Distribution Network,

Este post es una continuación del anterior sobre FastCGI y el IIS7, en Windows 2008 Beta 3 y Windows Vista, se incluye como soporte nativo FastCGI, lo que permite correr en maquinas Windows aplicaciones PHP y otros lenguajes de Script con altísimo rendimiento y estabilidad, incluso en ambientes en producción. El FastCGI CTP preview 2 también pueden montarse sobre IIS 5.1 y 6.0.

En este post, más allá de las instrucciones de cómo instalar una aplicación PHP en Windows Vista o Windows 2008, hablaré un poco de las razones por las que el rendimiento de las aplicaciones se incrementa al usar FastCGI.

Primero un poco de Antecedentes.

Common Gateway Interface (CGI)

El estándar de facto para aplicaciones en servidores web es CGI, que fue implementado inicialmente por el servidor NCSA. CGI tiene varios beneficios:

· Simplicidad. es fácil de entender

· Independencia del Lenguaje. Las aplicaciones CGI pueden ser escritas en cualquier lenguaje

· Independencia de Procesos. Ya que las aplicaciones corren en procesos separados, las aplicaciones con problemas no pueden dañar el servidor web o acceder al estado interno y privado del servidor.

· Estándar Abierto. Alguna forma de CGI ha sido implementada en todos los servidores web

· Independencia Arquitectónica. CGI no está atado a ninguna arquitectura particular de servidor 

CGI también tiene algunas deficiencias importantes. El problema principal es el rendimiento: debido a que se crea un nuevo proceso para cada request y este se elimina cuando el request se completa, la eficiencia es pobre.

CGI también tiene una funcionalidad limitada: solo soporta el Rol "responder", donde la aplicación genera la respuesta que es enviada al cliente, los programas CGI no pueden asociarse a otras partes del procesamiento del request como autorización o registro de errores.

APIs de Servidor

En respuesta a los problemas de rendimiento de CGI, diferentes compañías han desarrollado APIS para sus servidores. Los dos más relevantes son NSAPI de Netscape e ISAPI de Microsoft. El servidor Apache también tiene un API.

Las aplicaciones asociadas al API del servidor pueden correr mucho más rápido que los programas CGI. El problema del Inicio / iniciación se ha mejorado, ya que la aplicación corre en un proceso dedicado de servidor y se persiste entre las solicitudes. Las API del servidor Web, ofrecen mucha más funcionalidad que CGI, cada persona puede escribir extensiones que realizan control de accesos, acceder a los archivos de registro del servidor, y pueden conectarse en otras etapas del procesamiento del request. 

Entonces que es  FastCGI?

La interface FastCGI combina los mejores aspectos de CGI y las APIs propietarias. Como CGI, las aplicaciones FastCGI corren en procesos separados e independientes. Las ventajas de FastCGI's incluyen:

· Rendimiento. Los procesos FastCGI son persistentes –se re usan en manejar múltiples solicitudes. – Esto resuelve los problemas de rendimiento de CGI de crear nuevos procesos para cada request.

· Simplicidad, fácil migración desde CGI. La librería de aplicación FastCGI simplifica la migración de las aplicaciones CGI existentes. Las aplicaciones construidas con FastCGI pueden correr programas CGI para compatibilidad con Web Servers antiguos.

· Independencia de Language. Como CGI, las aplicaciones FastCGI pueden ser escritas en cualquier lenguaje.

· Independencia de Procesos. Una aplicación FastCGI con errores no puede corromper el core del servidor web o alguna otra aplicación. Una aplicación FastCGI no puede robar ningún secreto (como las llaves de sesión para encripción) del servidor Web.

· No-propietario. FastCGI es soportado por todo los productos del Open Source del Mercado, incluyendo apache, NCSA y ahora es soportado por servidores comerciales de Microsoft y Netscape.

· Independencia Arquitectónica. La interface FastCGI no está atada a ninguna arquitectura particular de servidor. Cualquier servidor puede implementar la interface FastCGI. De igual manera, FastCGI no impone ninguna arquitectura a la aplicación: las aplicaciones pueden ser single o multi-threaded, sin importar la arquitectura de hilos del servidor web.

· Soporte para computación distribuida. FastCGI prove soporte para correr aplicaciones remotamente, lo cual es útil para distribuciones de carga y manejo externo de web sites.

La interface FastCGI

La funcionalidad que provee la interface FastCGI es muy similar a la que provee CGI. Para entender mejor el protocolo FastCGI. El procesamiento de peticiones CGI es así:

1. Para cada Request, el servidor crea un nuevo proceso y el proceso se inicializa por sí mismo.

2. El servidor web pasa la información del request( como host remoto, nombre de usuario, encabezados HTTP, etc) a las variables  de entorno del programa CGI.

3. El web server envía cualquier input del cliente  (como valores entrados por el usuario en un formulario HTML) al estándar input del programa CGI.

4. El programa CGI escribe cualquier output para que sea retornado al cliente como salida estándar. La información de error es escrita por el web server.

5. Cuando el proceso CGI se cierra, la solicitud queda completa.

FastCGI es conceptualmente muy similar a CGI, con dos diferencias principales:

· Los procesos FastCGI son persistentes: después de finalizar una solicitud, los procesos quedan en espera en vez de finalizar. 

· En vez de usar variables de ambiente del sistema operativo y pipes,  el protocolo  FastCGI multiplexa la información del ambiente, el input  estándar, el output estándar y error sobre una conexión full-duplex. Esto permite a los programas FastCGI correr en maquinas remotas, usando conexiones TCP entre el servidor web y las aplicaciones FastCGI.

El procesamiento de una solicitud en una aplicación single-threaded FastCGI ocurre así :

1. El Web server crea la aplicación FastCGI para manejar las solicitudes al servidor. El proceso puede ser creado en el inicio o creado por demanda.

2. El programa FastCGI seinicializa  por sí mismo, y espera una nueva conexión con el web server.

3. Cuando llega una solicitud de un cliente, el servidor  web abre una conexión a los procesos FastCGI. El servidor envía la información de ambiente y el input estándar sobre la conexión.

4. el proceso FastCGI envía la salida estándar y la información de errores de regreso al servidor sobre la misma conexión. 

5. Cuando el proceso  FastCGI cierra la conexión, la solicitud se completa. El proceso FastCGI queda a la espera de otra conexión desde el servidor web.

Las FastCGI pueden correr localmente  (en la misma máquina que el web server) o remotamente. Para aplicaciones locales, el servidor usa un  full-duplex pipe para conectarse con el proceso de la aplicación  FastCGI . Para aplicaciones remotas, el servidor usa conexiones TCP.

Las aplicaciones FastCGI pueden ser  single-threaded or multi-threaded. para aplicaciones  single threaded, el servidor web mantiene un pool de procesos  (si la aplicación corre localmente) para manejar las solicitudes de los clientes. El tamaño del Pool es configurable por el usuario. Las aplicaciones FastCGI Multi-threaded pueden recibir múltiples conexiones del web server y manejarlas de forma simultánea en un solo proceso.  (De esta forma lenguajes, con soporte para multi thead, garballe collection, entre otros, lo hacen lenguajes naturales para implementar aplicaciones multithread usando FastCGI)

Roles de Aplicación.

Un problema importante con CGI es su funcionalidad limitada: los programas CGI solo proveen respuestas simples al request.  FastCGI provee funcionalidad ampliada con soporte para tres diferentes roles de aplicación: 

· Responder. este es el rol básico en  FastCGI y corresponde a la funcionalidad básica ofrecida por CGI hoy. 

· Filter. las aplicaciones FastCGI filtran los archivos solicitados al web server antes de que sean enviados al cliente. 

· Authorizer. El programa FastCGI realizan una decisión de control de acceso para el request ( por ejemplo realizando una búsqueda a la base de datos del tipo Usuario/password).

Otros roles serán definidos en el futuro. Por ejemplo,  un rol "logger" podría ser útil, donde el programa FastCGI podría recibir el registro del log del servidor para procesamiento y análisis en tiempo real. 

Que tan rápido es FastCGI?

La respuesta depende de la aplicación, algunas pruebas hechas en internet muestra lo siguiente:

En esta medición se usa un archivo, una solicitud CGI y una fastCGI, usando una aplicación que retorna un número fijo de bytes. 

Archivo  

21ms + 0.19ms per Kbyte

FastCGI

22ms + 0.28ms per Kbyte

CGI

59ms + 0.37ms per Kbyte

Con este dato podemos trata de calcular la velocidad después de migrar una aplicación típica CGI de base de datos a FastCGI, asumiendo que la aplicación toma 50ms para inicializar las conexiones a las bases de datos y genera 5k de datos. Los resultados finales pueden calcularse así: 

CGI

59ms + 50ms + (0.37ms)(5) = 111ms

FastCGI

22ms + (0.28ms)(5) = 23ms

En esta prueba, FastCGI tuvo una ventaja de rendimiento de 5x sobre CGI, más que nada debido a no tener que crear e iniciar un nuevo proceso para cada solicitud.

En resumen

FastCGI es un protocolo estándar que permite a ejecutables que usen Frameworks CGI interactuar con un Web Server.

La mayor diferencia con el Protocolo CGI Estándar es que FastCGI rehúsa los Procesos CGI para múltiples peticiones, lo que incrementa el rendimiento en comparación con CGI.

El soporte de IIS para FastCGI permite a IIS hospedar programas CGI normales como PHP, o Ruby On Rails, usando el protocolo FastCGI, ofreciendo alto rendimiento y estabilidad en ambientes de producción

Para usar el soporte  FastCGI en IIS se requieren tres elementos:

· El web server IIS (IIS5.1, IIS6, and IIS7).

· El componente FastCGI para IIS

· EL programa CGI que será hospedado.

Como funciona?

El servidor web despacha las solicitudes http que se han realizado a su aplicación usando el componente FastCGI, este a su vez lanza el programa ejecutable CGI y reenvía el request para que sea procesado. Una vez la solicitud se procesa y la respuesta se finaliza y es retornada al servidor y al cliente, el proceso CGI es usado para llamadas siguientes. Esto permite evita las penalidades de alto rendimiento de iniciar un nuevo proceso para cada solicitud, lo que resulta en mucho mejor rendimiento y escalabilidad en ambientes de producción.

El protocolo FastCGI es estándar si quiere tener más información sobre FastCGI puede ver más aquí. http://www.fastcgi.com/devkit/doc/fcgi-spec.html.

El paquete FastCGI es totalmente compatible con la distribución actual y oficial  PHP 5.x disponible para Windows desde  www.php.net/downloads. También puede usar el preview de Fast CGI con la instalación existente de  PHP 5.x (sin embargo usar la versión ThreadSafe incrementa el rendimiento hasta un 30%)

La versión 5.2.3 también contiene las mejoras desarrolladas por Zend para mejorar el rendimiento del motor de PHP sobre Windows.

Espero que sea de Ayuda

Juan Carlos Peláez

MCTS

Miembro del Microsoft Speaker Group Andino  

Miembro del Microsoft Influencers Group de Colombia.

Keywords: PHP, FastCGI, Windows Vista, Windows 2008, IIS7, Arquitectura.

Aunque no sé si sea  un escenario muy común, (para nosotros en Gattaca si lo es), hay aplicaciones legacy escritas en ASP clásico que empiezan a integrarse con aplicaciones en .Net, bien sea como parte de un proceso paulatino de migración o como parte del proceso de agregar nuevas funcionalidades a la aplicación existente, en ambos escenarios una forma simple de integrar la aplicación asp con la nueva aplicación .net es exponer las nuevas funcionalidades de la aplicación .Net por medio de servicios web.

Aunque existe en La Red literatura respecto a la forma como debe hacerse esta invocación del web service desde la página web no todos los ejemplos apuntan a escenarios reales, el objetivo de este post es mostrar cómo debe realizarse esta integración para aplicaciones del mundo real.

1. El primer problema consisten en identificar cuáles son los tipos de datos que se van a transferir entre la aplicación asp y la aplicación .net, mi recomendación es pasar datos de tipos básicos del CRL, es decir, strings, longs, integers. Aunque es posible pasar objetos representados como XML para que después sean des-serializados por la aplicación .net esto complica bastante el escenario e incluye nuevos elementos de error. (Nosotros transferimos solo strings y creamos los objetos en la aplicación .net, para lo cual creamos los constructores adecuados)

2. El siguiente problema es identificar quien es el realmente el cliente del servicio, en la mayoría de los escenarios el cliente del servicio es código del lado del servidor, (el código que esta entre los tags <%%> es el código del servidor), también es posible que el cliente sea alguna de las funciones JavaScript de la página que se quiere invocar. (Este es el escenario que derivo en la existencia de AJAX Asynchronous JavaScript And XML).  Por ahora nos enfocaremos en el escenario donde el código del lado del servidor es quien consume el web service.

3. Ahora debemos seleccionar la forma como se comunicará la aplicación asp con el servicio web, básicamente hay dos opciones, usar SOAP, o usar el parser de xml (HTTP Post) que contiene un objeto poco conocido llamado MSXML2.ServerXMLHTTP que puede ayudarnos a realizar estas llamadas. Básicamente es un tema de gusto, facilidad y conveniencia, sin embargo como es necesario tener instalado el Toolkit de SOAP para poder usar los objetos de SOAP desde asp clásico y dicho componente se queda sin soporte a partir de Marzo 31  del 2008, entonces nosotros preferimos usar HTTP Post.

4. Bien lo siguiente es escribir el código del servicio web y modificar la página asp para que lo consuma, lo del servicio web no lo vamos a profundizar, es una clase con la decoración webservice con algunos métodos decorados webmethod, etc. un ejemplo sencillo puede ser algo como esto:

Imports System.Web.Services
Imports System.Web.Services.Protocols
Imports System.ComponentModel

<System.Web.Services.WebService(Namespace:="http://MyNameSpace/services/MyProduct> _
<System.Web.Services.WebServiceBinding(ConformsTo:=WsiProfiles.BasicProfile1_1)> _
<ToolboxItem(False)> _
Public Class WorkFlowServices
    Inherits System.Web.Services.WebService

    <WebMethod()> _
    Public Function ServiceTest() As String
        Return "En Ejecucion..."
    End Function

    <WebMethod()> _
    Public Function MyMetodoconParametros(ByVal Client As String, ByVal UserID As Long, ByVal IDProcessCase As Long, _
                                                ByVal Sequence As Long, ByVal EntryDataType As String, ByVal IDEntryData As String, ByVal EntryData As String) As Long

...hacer algo, retornar algo.

    End Function

End Class 

5. Ahora como consumir este web service desde la página asp clásica, es algo como esto:

<%

Dim xmlhttp

Dim DataToSend

Dim postUrl

postUrl = "http://IPMyServer/Services/WorkFlowServices.asmx/MyMetodoconParametros"

DataToSend="Client=Tester&UserID=1&IDProcessCase=80&Sequence=0" & _

"&EntryDataType=TestWebService&IDEntryData=0&EntryData=1"

 

Response.write postURL

Response.write "<br>"

 

Set xmlhttp = server.Createobject("MSXML2.ServerXMLHTTP")

xmlhttp.Open "POST",postUrl,false

xmlhttp.setRequestHeader "Content-Type","application/x-www-form-urlencoded"

xmlhttp.send DataToSend

 

Response.Write(xmlhttp.responseText)

%>

Lo importante de este segmento de código, es la forma como se construye la invocación del método, la variable postURL tiene la dirección del servicio web asi como el nombre del método que se va a invocar. Luego la variable DataToSend tiene la información de los valores que toman los diferentes parametros que se van a pasar al metodo del web service (la recolección de estos parámetros depende del tipo de uso e interfaz que se tenga con los usuarios pero puede ser la recolección de una forma usando request.form o la recolección de los parámetros del QueryString que invocó la páginas ASP).  

Otra cosa importante es la definición del encabezado en la linea xmlhttp.setRequestHeader "Content-Type","application/x-www-form-urlencoded" .

Listo, se invocó el web service, ahora el resultado puede recuperarse de una de estas propiedades: responseBody, responseStream, responseText, and responseXML., (nosotros usamos response.text que nos retorna todo el entity body como un stream)

Tips Súper Importantes:

· Cuando su cliente del servicio web sea el propio código asp ("del lado del servidor") se recomienda usar el objeto MSXML2.ServerXMLHTTP que ha sido diseñado y optimizado para comunicaciones entre servidores.

· El código anterior genera un error en la mayoría de los servicios web del framework 2.0, es un error del tipo "Request format is unrecognized for URL" o en español "Formato de solicitud no reconocido para la dirección URL" esto se debe a que los protocolos Get y Post estan deshabilitados por omisión (default) en las aplicaciones del framework 2.0 para todas las peticiones de orígenes diferentes a Localhost. (Esa es la razón por la que la página de prueba de los servicios web como se ve desde otra maquina no tiene el formulario Test Service), por lo tanto para que efectivamente se realice la invocación hay que habilitar estos protocoles, eso se hace incluyendo las siguientes líneas en el archivo web.config del servicio web de .net.

<system.web>

    <webServices>
        <protocols>
            <add name="HttpGet"/>
            <add name="HttpPost"/>
        </protocols>
    </webServices>

(...)

</system.web>

En este articulo hay más información del comportamiento de los protocolos, aunque solo habla del framework 1.1. también ocurren con en el framework 2.0.

Espero que sea de utilidad

Juan Carlos Peláez
MCTS

Keywords: Web Services, ASP Clasic, .Net, Framework 2.0, VB, "Formato de Solicitud no reconocido",