Holas!

He decidido retomar mi blog! Saludos y mucha fuerza para todoes en esta pandemia que estamos viviendo! 

Muy interesante para saber sobre los estándares que deben cumplir los futuros proyectos en la web!!!

Adopción de estándares web

Los estándares web afectan a cuatro categorías amplias: La validez del código, la navegación de sitios, la accesibilidad y la separación de contenido y diseño, tal como se muestra en la figura 1. Desde el punto de vista de los problemas más importantes de estas categorías, el objetivo de generar código conforme con los estándares se consigue en gran medida. Echemos un vistazo a cada categoría.

  Figure 1 Categorización de estándares web

Estándar	Descripción
Validez del código	Los sitios web deben usar XHTML y CSS válidos de acuerdo con los estándares del W3C y tener el formato adecuado. Esto garantizará la máxima compatibilidad con el explorador, una representación más rápida y un código más fácil de entender.
Navegación de sitios	Los sitios web deben tener una estructura jerárquica con un mapa del sitio y direcciones URL sencillas. Los usuarios deben poder determinar su ubicación en un sitio según la dirección URL.
Accesibilidad	Los sitios web deben estar disponibles para los usuarios discapacitados y en un amplio abanico de exploradores y dispositivos.
Separación entre diseño y contenido	Los sitios web deben usar una hoja de estilo para definir la disposición y la presentación con contenido representado en XHTML.

XHTML y jigsaw.w3.org/css-validator para CSS. Estos servicios se pueden automatizar como parte del proceso de generación o realizarse manualmente antes de implementar el código.

La mayoría de los exploradores están evolucionando para cumplir los estándares web. Es el caso de Internet Explorer ® 7.0 y Mozilla Firefox 2.0, que se lanzaron a finales de 2006. De modo que, si aplica sus estándares web, puede estar mucho más seguro de que el código se mostrará correctamente en los exploradores actuales.

Mas info en http://msdn.microsoft.com/es-es/magazine/cc163438.aspx

Implementación de Colas  MSMQ

Seleccionar en Control de Panel “Agregar o Quitar Programas” y en el “Asistente para componentes de Windows” activar “Message Queue Server”

Posteriormente en la ventana de comandos ejecutar el Administrador de Equipo (Computer Management ) ubicándose en Mi PC clikc derecho Administración.

Activar el Servicios de Aplicaciones para llegar a la opción Message Queue Service, seleccionar la carpeta Colas Privadas y con click derecho seleccionar Nuevo

Luego  en Visual Studio se agrega un proyecto de la plantilla Visual C# seleccionar Windows, y será de tipo Aplicación Consola la cual llamaremos AplicaciónCliente donde creará por default la clase Program.cs  el cual se deberá renombrar a Cliente.cs

Dentro de Program se cra la clase Cliente

La public class Cliente {}

 declara un arreglo:  static void Main(string[] args)

declara una variable llamada rutaCola

string rutaCola = @".\private$\Pruebas";

           

el nombre debe coincidir con el nombre creado en el Message Queueing del Computer Managment

y se debe generar un condicional:

if (!MessageQueue.Exists(rutaCola))

            MessageQueue.Create(rutaCola);

            MessageQueue cola = new MessageQueue(rutaCola);

            Message mensaje = new Message();

            mensaje.Label = "Nueva nota";

            mensaje.Body = new Nota() { Alumno = "Magdalena", PC1 = 19 };

            cola.Send(mensaje);

            Console.ReadLine();

Donde verifica si el mensaje existe en la carpeta del Message Queue Server del Panel de Control, para lo cual en la carpeta References de la Clase AplicaciónCliente se agrega la referencia System.Messaging de la pestaña .Net

Si no existe el mensaje se crea con el método Message() al cual se le agrega un titulo, y el cuerpo con valores fijos (hardcodeado).

Luego se genera la clase Nota donde se declara las variables de los valores generados en el método anterior.

public class Nota {}

y dentro de esta clase se crean las variables Alumno y PC1 Que corresponderá a la Nota1

public string Alumno { get; set; }

        public int PC1 {get; set;}

A continuación se ejecuta la Aplicación Consola generada en el Visual Studio

Aparecerá una pantalla indicando que ya se está generando el envío del mensaje desde el cliente a la cola del servidor .

Para poder ver el mensaje ir a Mi PC, click derecho Administrar y se podrá visualizar en Administración de equipos, dentro de Servicios y Aplicaciones, en la opción Message Queue Service.

En este ejemplo se ha realizado un mensaje generado desde el aplicativo Visual Studio (valores hardcodeados) - Cliente hacia Message Queue Server del windos –Servidor.

 Ahora se realizará al revés. Se tomará el mensaje de Cliente a Servidor , (Message Queue Server) y este será enviado a la consola cliente : Se agrega un proyecto de la plantilla Visual C# (seleccionar Windows)  y será de tipo Aplicación Consola la cual llamaremos AplicaciónServidor  donde creará por default la clase Program.cs  el cual se deberá renombrar a Servidor.cs

A continuación se muestra  el código de dicha clase comparándolo con el código anterior  y viendo sus diferencias:

De igual forma en la Clase AplicaciónCliente se tiene que agregar la referencia System.Messaging en en la carpeta References  desde la pestaña .Net

Se puede observar que la lógica es la misma,  solo que después del envío del mensaje de cliente a servidor, verifica que este exista. Si existe utiliza la misma variable de la ruta para una segunda cola,  por la cual recibirá el segundo mensaje , el cual estará compuesto por los valores de las variables del primer mensaje concatenadas con las del segundo mensaje.

Me despido compartiendo este hermoso mensaje:
http://www.youtube.com/watch?v=i5ZnUlV9bNU

Hola chicos!
Aqui mi blog.... y para iniciarlo un tema del curso de Desarrollo de Sistemas Distribuidos el cual se ha visto durante todo el modulo 2 del ciclo 2012-01 :)

Gráfico de la reseña de la Web en los últimos años

Cuando se inicio el curso inicialmente tuvimos que ir directo a lo que era los conceptos principales que caracterizan a los Sistemas Distribuidos: Colección de computadoras independientes que dan alusuario la impresión de constituir un único sistema coherente.

De igual forma se distinguió las diferencias de cada tipo de servicio entre ellos los mas populares SOAP y RESTfull.
   

Diferencias entre REST y SOAP en el proyecto condominios

Como podemos apreciar en la clase IResidente de SOAPService se observan las llamadas a los métodos CrearResidente, ObtenerResidente, ModificarResidente y EliminarResidente los cuales han sido implementados en DAO dentro de la carpteta persistencia de la Clase SOAPServices. Mientras que en el servicio REST se aprecia la Clase IResidente donde en vez de llamar a métodos ejecuta los 4 metodos HTTP conocidos como los 4 verbos CRUD(Create, Retrieve, Update y Delete) propios del HTTP acompañado del UtiTemplate que hace mencion al recurso que en este caso es la clase del Servicio.

Imágenes del Servicio SOA implementado en el proyecto Condominio

Como podemos apreciar el la solución al proyecto Condominios se ha creado inicialmente un Servicio llamado Soap Services donde se puede visualizar el código para la historia Residentes la cual esta dentro de la carpeta persistencia de dicho servicio. 

Imágenes del Servicio REST implementado en el proyecto Condominio

Posteriormente se creó otra Servicio tipo WCF llamado RESTServices donde se implementó también el modelo de dominio con contrato a la BD, posteriormente se implementa la capa de persistencia  generando el ConexionUtil.cs  donde se agrega el nombre de la Base de Datos.

La diferencia se ve en el la propiedad View Mark de Residente.svc del Servicio RESTService el cual tiene agregado la línea:

Factory = "System.ServiceModel.Activation.WebServiceHostFactory"

sin presentar la conexción SOAPService

como se puede compara con el View Mark de  Residentes.svc de SOAP Services que contiene el siguiente código. 

Ambos servicios se ejecutan de forma normal.

Arquitectura Orientada a Servicios (Service-Oriented Architecture, SOA).

Los Servicios Web pueden también ser implementados siguiendo los conceptos de la arquitectura SOA, donde la unidad básica de comunicación es el mensaje, más que la operación. Esto es típicamente referenciado como servicios orientados a mensajes.

Los Servicios Web basados en SOA son soportados por la mayor parte de desarrolladores de software y analistas. Al contrario que los Servicios Web basados en RPC, este estilo es débilmente acoplado, lo cual es preferible ya que se centra en el “contrato” proporcionado por el documento WSDL, más que en los detalles de implementación subyacentes. 

Mas adelante se presentará un ejemplo Servicio SOAP utilizado en el Proyecto Condominios implementado por el grupo de trabajo "SOA"

Arquitectura REST (Representation State Transfer)

Concebida por roy fielding quien trabajo mucho en los establecimientos de algunos de los estándares y versiones de HTTP y HTLM cuando comenzó la Web (Inicio de las Web Sites 1992 como se puede ver en el gráfico superior)  

La idea de Filelding es Mantener muchos de los estilos arquitectónicos que tiene que ver con el desacoplamiento  y mantener  interfaces uniformes para algunas cosas que están por arriba de lo que conocemos como web tradicional Tradiciona basado en: HTTP (canal / protocolo de comunicación de bajo nivel)   y sobre esto van los esto  Artefactos de texto HTML y compartir documentos compartir documentos y características como URL, links y básicamente a pesar de que se tienen varios servicios arriba de la web tradicional, usando script , Ayax, Flash, Silverlight etc,  se pueden hacer cosas más sofisticadas pero de fondo la web sigue siendo lo mismo Http.

La arquitectura de software lo que trata de crear estrategias y comunes sobre el  manejo de la complejidad. La construcción de software es cada vez más compleja, convivimos entre protocolas y tecnologías y muchas cosas por encima. por tal hay que reducir la complejidad. Hay que usar un Mecanismo de particionamiento del problema de forma sencilla.  La solución sigue siendo compleja; pero la solución es repartirla el problema en partes sencillas.

Hay que usar mayor capas de abstracción ejemplo: Inicialmente se trabajo en Lenguaje de máquina,  luego Orientación a Objetos, luego Orientación a Servicios  y cada vez hay que crear mayores capas de abstracción uniforme tal que la complejidad no sea evidente.

Características básicas de REST y SOAP

      Encontré dos frases interesantes sobre la característica de cada servicio a nivel de protocolo como se puede observar en el siguiente gráfico:

REST  “La Web es el universo de la información accesible globalmente”

SOAP “La Web es el transporte universal de mensajes”

A nivel de protocolos, las aplicaciones de REST pueden publicar su data en la Web a través de URI, mientras que las aplicaciones en SOAP tienen solo la oportunidad de interactuar pero sobre la Web.