Error HTTP 503 Servicio no disponible

El 503 es un error que los navegadores muestran cuando el servidor al que se intenta acceder, se encuentra sobrecargado. Las causas más comunes en servidores corrientes son variadas. Y con corrientes me refiero a los normales, que seguramente son algo más pequeños que los que debe tener Google:

Uso abusivo del servidor. Es el caso de los ataques D.O.S. y otros similares en las que se generan malintencionadamente, una gran cantidad de solicitudes (peticiones que se hacen para obtener los datos necesarios para mostrar una página).

Picos temporales de usuarios. De forma no maliciosa. Simplemente cuando coinciden demasiados usuarios accediendo al servidor simultáneamente. 

Demasiadas visitas de bots. Los spiders que rastrean La Red trabajan con una incansable actividad para sus correspondientes buscadores. En un principio esto es lo propio y lo deseable para los que quieran ser indexados, pero en ocasiones también puede ser un problema cuando se ceban con uno.

Programas ineficientes. Es el caso de un Script que propicie un uso excesivo del servidor o que incluso entre en bucle por estar mal programado.

Excesivo tráfico. Si uno o varios sitos colgados de un servidor tienen un éxito tremendo y repentino, la capacidad del servidor se puede ver desbordada mientras que el administrador incrementa su capacidad.

Básicamente se deben realizar las siguientes acciones para identificar y solucionar este error:

- Ejecutar VS como administrador
- Verificar si el puerto 80 está utilizado por otro servidor diferente al IIS
- Confirmar que la cola tiene permisos para todos
- Verificar que existe el directorio virtual para la aplicación en el IIS
- Verificar que se colocó isOneWay=true en la interfaz del servicio y que se borró address="" del web.config

¿Dónde es útil REST? 

Tanto los arquitectos como los desarrolladores necesitan decidir cual es el estilo 

adecuado para las aplicaciones. En algunos casos es adecuado un diseño basado en 

REST, se listan a continuación: 

• El servicio Web no tiene estado. Una buena comprobación de esto consistiría en 

considerar si la interacción puede sobrevivir a un reinicio del servidor. 

• Una infraestructura de caching puede mejorar el rendimiento. Si los datos que el 

servicio Web devuelve no son dinámicamente generados y pueden ser 

cacheados, entonces la infraestructura de caching que los servidores Web y los 

intermediarios proporcionan, pueden incrementar el rendimiento. 

• Tanto el productor como el consumidor del servicio conocen el contexto y 

contenido que va a ser comunicado. Ya que REST no posee todavía (aunque 

hayamos visto una propuesta interesante) un modo estándar y formal de 

describir la interfaz de los servicios Web, ambas partes deben estar de acuerdo 

en el modo de intercambiar de información. 

• El ancho de banda es importante y necesita ser limitado. REST es 

particularmente útil en dispositivos con escasos recursos como PDAs o teléfonos 

móviles, donde la sobrecarga de las cabeceras y capas adicionales de los 

elementos SOAP debe ser restringida. 

• La distribución de Servicios Web o la agregación con sitios Web existentes 

puede ser fácilmente desarrollada mediante REST. Los desarrolladores pueden 

utilizar tecnologías como AJAX para consumir el servicio en sus aplicaciones Web.

WebFaultException en Servicio WCF

Una de las excepciones que se manejaron en la elaboración del proyecto fueron los WebFaultException, los cuales se implementaron en el Servicio de Unidades (REST) en donde se creo nuestra clase UnidadException la cual contenía nuestro mensaje de error personalizado como se muestra en la imagen.

Para poder asi en el Controller a través del catch (WebException) obtener el mensaje definido en nuestro servicio.

Leer datos de una Cola cuando el servicio este disponible nuevamente

Durante la implementación de nuestro proyecto se genero la duda de como se deberían obtener los datos desde la cola generada cuando el servicio no esta disponible, así que después de realizar una investigación se obtuvo que con la siguiente sentencia nos permitía saber la cantidad de mensajes que se encuentran alojados en este caso en nuestra cola de clientes:

Por lo que después recorríamos los datos y por cada uno generábamos el registro de nuestro servicio CrearCliente como se muestra en la imagen inferior.