• Save
Web service
Upcoming SlideShare
Loading in...5
×
 

Web service

on

  • 4,172 views

Web Service 2010

Web Service 2010

Statistics

Views

Total Views
4,172
Views on SlideShare
4,172
Embed Views
0

Actions

Likes
3
Downloads
0
Comments
1

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • yyy
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Web service Web service Document Transcript

  • Curso Web Services 2010 Módulo 01 Introducción WCF Unidad 1 Visión general de la arquitectura Historia al principio aplicaciones locales, luego empezaron las aplicaciones de red, luego cliente-servidor, luego aplicaciones distribuidas (atacan a varios servidores) Servicios: entes, objetos, recursos de otros ordenadores a los que podemos ir llamando. WCF: servicios que pueden estar alojados en el IIS, en una aplicación, … Orientación a objetos Clases: Abstracción de un objeto. Objeto: Una instancia de una clase. Herencia: Las clases hijas heredan de otra Polimorfismo: Dos métodos se llaman igual pero se comportan distinto dependiendo de la clase Sobrecarga: Podemos sobrecargar un método de la clase padre para que funcione distinto en el hijo. SOA: Arquitectura orientada a servicios. Podemos tener la lógica de negocio en servicios que serán consumidos por otros servicios o por una interfaz, a través del paso de mensajes (normalmente en XML) SOAP: Protocolo de acceso simple a objetos. Protocolo estándar que define como dos objetos pueden comunicarse por intercambio de XML. Deriva del XML-RPC. Servicios Web: Conjunto de protocolos para intercambiar datos entre aplicaciones. Patrón Proxy: Los servicios WCF utilizan la clase Proxy. Es transparente a nosotros pero hay que referenciarla . WSDL: Es el “contrato” nos dice qué es lo que hace la clase, qué recibe y qué devuelve. Cuando nos conectamos a un servicio Web, lo primero que vemos es una página que nos dice que servicios tiene y nos podemos descargar el contrato.
  • WINDOS COMUNICATION FUNDATION Es una implementación más a los servicios Web. (a finales del 2005) con el .NET 3 La palabra clave es comunicación, me da igual donde esté el servicio, quiero consumirlo. Tenemos varios elementos: - Interfaz: clase interfaz en la que definimos el contrato de clases y métodos (antes sólo eran métodos) - Implementación: Es una clase que implementa el contrato. Definiremos los métodos de la interfaz - End-Point: Punto de entrada. Se dice donde está el servidor, cual es la unión,… es un XML. (se puede cambiar en caliente) - Binding: Tipo de conexión con el servicio. Unidad 2 Implementación de un WCF En V Studio create Project – En Web: WCF Service Application crea un servicio preparado para alojarlo en IIS. En WCF tenemos: - Secuential WorkFlow Service Library: Crea un servicio de un workflow secuencial (empieza y acaba) - Maquina de estados: tiene workflows y un estado. - Syncication: - WCF Service Library: es el típico, normalmente se crean o este o el web (en el 90% de los casos para publicarlo en el IIS) Tipo de alojamiento: - IIS - Propia Aplicación - Servicio Windows Ejemplo: Creamos un proyecto Web: WCF Service Aplication
  • Hacemos doble click en el fichero IService1.cs Antiguamente sólo podíamos crear Web Service de métodos, ahora con WCF se pueden compartir también datos. Creamos una nueva clase en la que definimos datos. CompositeType El archivo Service1.svc no lo tendría si no fuese Web. Le damos botón derecho al proyecto y Build y luego a play, aparece una lista de ficheros y pinchamos en el csv y nos aparece la definición de métodos,… del servicio, si pinchamos el enlace superior aparece todo el detalle. Práctica: 1. Abrir VS2008 y crear un proyecto WCF Service Library 2. Eliminar contrato de datos 3. Modificamos el interfaz para que tenga la operación de suma de dos números. (sólo la definición) [ServiceContract] public interface IService1 { [OperationContract] int GetSuma(int Num1, int Num2); 4. La implementación la hacemos en el archive Service1.cs
  • 5. Para ejecutar - botón derecho – debug y ejecutar. Sale una ventana WFC Test Client y hacemos doble clieck en get suma, ponemos los dos valores y le damos a invoke.
  • Creamos el proyecto de test: Ponemos al principio #region Autogenerado para quitar todo el código que genera por defecto y al final el #endregion
  • Sobre el proyecto de test añadimos la referencia al servicio: Le damos al botón discover y nos descubre el que tenemos, lo seleccionamos y abajo ponemos Proxy (en el NameSpace) Si abrimos el AppConfig vemos el timeout del servicio, el nombre,… Creamos el código de test: public void TestSuma() { Proxy.Service1Client prx = new TestProject1.Proxy.Service1Client(); int resultado = prx.GetSuma(4,5); Assert.AreEqual(9,resultado); }
  • Para ponerlo como servicio de arranque: Ponemos un punto de interrupción con el F9 y pulsamos F5 Si cambiamos el 9 en el assert saldría un botón rojo y si hacemos doble click en el botón rojo dice lo que esperaba y lo que recibe:
  • Módulo 02 Configuración y alojamiento La llamada se hace a través de la clase proxy. Tres tipos de alojamientos: - IIS : - Servicio de Windows: - Aplicación Host Figura del listener: ente que está escuchando continuamente peticiones (servicio), en el IIS el mismo es el listener, en el servicio Windows es él mismo, y en la aplicación host, el listener es el servicio. Características de un servicio: - Q se pueda levantar y parar - Q escuche peticiones y redireccione. - Para la configuración se usan los endpoints Endpoints están formados por tres partes: - La dirección: IIS: http://loclahost:… Aplicación host: xxxx.svc - El binding: Contiene: o El protocolo de transporte y tiene que coincidir con el que esté en el servicio. Un servicio puede escuchar varios tipos de transporte. o La codificación del mensaje: casi siempre XML SOAP (en sistemas de alto rendimiento y si los dos extremos los desarrollan los mismos, en binario) o Requisitos de seguridad: cada protocolo tiene sus limitaciones y sus requisitos. (p ej: el http traspasa los firewalls (da menos problemas)) o Que el servicio sea transaccional: que podamos lanzar varias transacciones y si no se realizan todas que lo deje en el estado anterior. o Fiabilidad de la comunicación con el servicio (normalmente no estarán en la máquina, sino habríamos hecho una dll. Antes de hacer nada comprobar que el servicio responde. - El contrato: o Almacenado en un ensamblado y marcado con el nombre: ServiceContract
  • o Define las operaciones y datos. Tanto los datos de las operaciones como los definidos en el contrato deben ser serializables (normalmente van a ser de tipo string, entero, fecha…) El tipo de alojamiento más típico es en IIS. Se despliega como una página Web. - Creamos el directorio virtual - Asignamos el Framework 2.0.5 ( - Configurar el endpoint (estará en el webconfig) - La dirección del servicio es la que nos lleva al archivo svc: (p.ej. http://localhost:8080/aplicacion/archivo.svc. este archivo tendría un enlace a la descripción del servicio. Alojamiento en una aplicación host. Opciones: - Aplicación que levante y pare el servicio. - Alojar el servicio en un servicio Windows. - Utilizar el IIS7 (WAS) esto no lo veremos seguramente en este curso. Aplicación Host: - Arranca, para y pausa el servicio. - Utiliza la clase ServiceHost (System.ServiceModel) - Ver ejemplo en presentación - Eventos: Openning, opened, colsing, closed, faulted (error que ha creado) Alojamiento en servicios Windows: - Creamos un proyecto de tipo Windows Service y agregamos el WCF, en el start arrancamos el servicio y en el stop del servicio Windows paramos el nuestro. - Hagamos la práctica 2 (per tiene que ser un WCF aplication pero de Web Ahora vamos a crear el proyecto Web: Creamos un proyecto Web ASP.NET Web Application dentro de nuestra solución
  • Añadimos la referencia al servicio:
  • Le damos a design y añadimos un botón, un label y un texto y añadimos código en el onclick Ponemos el WebAaplication1 como startUp Project y el default.aspx como start page (botón derecho en cada uno) y le damos al play de arriba.
  • Modulo 03 Gestión de EndPoints Dentro del WebConfig tendremos el ServiceModel con los distintos comportamientos que sólo tienen un atributo “Name” endPointBehavior (cómo se comportan los extremos) Es posible crear varios endPoints en el cliente y en el servicio y el cliente puede elegir por qué endpoint se va a conectar. Se puede decir: si el servicio es localhost te conectas por tcp (y así la comunicación es binaria), sino, si es http siempre va a salir al menos al servidor DNS En el Visual Studio dentro de Tools – hay una aplicación WCF Service Configuration. En el construstor de la clase proxy le diremos porqué endpoint se tiene que configurar: Proxy.ServiceClient pr = new….(nombreendpoint) IIS6 sólo admite correcciones http, pero no tcp. En el IIS7 sí lo admite pero es bastante complejo de configurar. Cada binding es único en cada endPoint. BasicHttpBinding: puede ir en http y https, codificación en XML y mantiene compatibilidad con servicios asmx. WSHttpBinding, permite MTOM (permite meter binarios dentro de un XML). WSDualHttpBinding: similar al anterior pero permite conexiones duplex. (full duplex ¿?) WSFederationBinding: opera con varios niveles de seguridad NetTCPBinding: primer protocolo que va por TCP, codificación binaria, mayor rendimiento pero menos operatividad (sólo se puede consumir de los que utilicen el mismo modelo de objetos) NetPeerTcpBinding: usa tuberías, conexiones seguras y codificación binaria. NetNamedPipeBinding son tuberías con nombre, gran rendimiento, no funciona a través de la red (parecido a una dll) NetMsmqBinding: usa Msf Message Queue, permite aislamiento temporal (los mensajes se quedan en la cola) Msmq… basada en el anterior pero la cola es bidireccional
  • Modulo 4 Depuración y diagnóstico Cuando se compila en modo release el depurador hace varias optimizaciones. Cuando debug=true no hay timeout. Cuando se vaya a pasar a producción hay que compilar en modo release. Aunque pongas debug=false en el config significa que no se puede depurar pero si está compilado en modo debug el rendimiento final no será bueno. Práctica Para publicar el servicio en el IIS copiamos la carpeta del servicio que está en: En el directorio del IIS (wwwroot)
  • Arrancamos el admin de IIS Herr. Admin. Permitimos todo para que no nos de problemas Desplegamos los sitios Web, botón derecho en nuestra carpeta – propiedades y le damos al botón crear (para que cree nuestra aplicación) y en la pestaña ASP.NET seleccionamos el 2.0xxxx
  • Aquí veremos la dirección del servicio al que podemos llamar desde nuevas aplicaciones (la dirección hasta el .svc
  • Creamos un nuevo proyecto. P.ej. creamos un proyecto Web .NET, añadimos la referencia al servicio pero en vez de discover ponemos la dirección
  • Ahora vamos a crear una aplicación Windows Forms que tenga un botón para arrancar el servicio y otro para que lo pare. Creamos el proyecto de tipo Windows Form Aplication. En este caso no añadimos la referencia al servicio, sino que agregamos la referencia a la DLL (ya que no queremos consumir el servicio, sino arrancarlo y pararlo). Añadimos también el system.servicemodel
  • El código que añadiremos será: using System.ServiceModel; //Añadimos el using del servicemodel y de nuestra dll using WcfService1; namespace Practica4_WindowsForms { public partial class Form1 : Form { ServiceHost pr; public Form1() { InitializeComponent(); pr = new ServiceHost(typeof(Service1), new Uri("http://gn708y8wyaiyeq5/WcfService1/ Service1.svc")); //esta es la dirección donde va a escuchar el servicio ¿? Si paramos el IIS y copiamos esto en el navegador no va a dar nada. } private void BT_Parar_Click(object sender, EventArgs e) { pr.Close(); label1.Text = pr.State.ToString(); } private void BT_Arrancar_Click(object sender, EventArgs e) { pr.Open(); label1.Text = pr.State.ToString(); } }} Para que funcione, copiamos el fichero config, del servicio IIS, lo copiamos en el escritorio, le cambiamos de nombre (de web.config a app.config) y lo pegamos en la carpeta de la
  • aplicación. Ojo mejor abrir los ficheros y copiar el contenido de uno a otro. Copiando los ficheros da un error ¿? Si ejecutamos sin copiar ese fichero da un error:
  • Diseño y definición de contratos Los contratos se generan en el archivo WSDL. (se accede en el enlace que aparece en la parte superior del archivo iservice1 (aquí ponemos las operaciones y datos que queremos compartir). En el archivo iservice definimos las funciones y datos y en el Service los desarrollamos. Buenas prácticas: - Tener un criterio a la hora de denominar los servicios,… Malas prácticas: - Utilizar el servicio como un cajón desastre que hace de todo. (difícil de mantener) Compromiso de rendimiento vs arquitectura.(tampoco es bueno crear un servicio para cada operación) Ficheros: Web.Config (configuración) Nombre.svc (para el IIS le dice en qué fichero está el código y poco más) Nombre.svc.cs (en este fichero es donde está el código) iNombre.cs (es en el que se define el contrato de datos y de operaciones y en el que aparece el acceso al WSDL Ejemplo de contrato: Creamos un proyecto Web WebService: namespace WcfService2 { // NOTE: If you change the interface name "IService1" here, you must also update the reference to "IService1" in Web.config. [ServiceContract] public interface IService1 { [OperationContract] // Esta función recibe parámetros y devuelve un objeto de la clase cliente Cliente GetCliente(string nombre, string apellido, string dni, int edad, string direccion); [OperationContract] int CumplirAnnos(Cliente c1;
  • } // Creamos un contrato de datos para la clase cliente [DataContract] public class Cliente { [DataMember] public string Nombre { get; set; } [DataMember] public string Apellidos { get; set; } [DataMember] public int Edad { get; set; } [DataMember] public string DNI { get; set; } [DataMember] public string Direccion { get; set; } } } OperationContractAttribute y ServiceContractaasttribute Pertenecen a la clase ServiceModel
  • El estar entre corchetes es porque son atributos pero cumplen los requisitos de la clase. Lo que pongas debajo son objetos de la clase OperationContract. Si ponemos un paréntesis salen los posibles parámetros (asyncPattern, llamo y no espero a la respuesta.IsOneWay (si la función no devuelve nada) isTerminating (cuando termines desconecta), protectionlevel (None, Sign, EncryptAndSigned), Action (podría ser una url con otra acción ¿?) isInitialiting (si es un método de inicio, a partir de ese método se ejecuta otro) P.ej: [OperationContract(AsyncPattern= true, IsTerminating=true] Normalmente no se llama con parámetros. - Servicio de operaciones sin datos (son los que hemos hecho hasta ahora, borrando la parte de datos) Si ponemos un paréntesis en el DataContract(:
  • Se aconseja no poner parámetros en el DataContract En el DataMember sí hay una propiedad interesante: EmitDefaultValue (bool): le puedes poner un valor por defecto que se informarán automáticamente. IsRequired(bool): si es obligatorio ese valor para poder generar la clase. Practica1: crear una aplicación Windows forms que consuma el otro servicio. Tenemos que copiar la dirección que pusimos en el Uri(“”) el otro día e incluir un Service reference a esa dirección. Para comprobar que no lo está utilizando con el IIS paramos el servicio IIS para ver que funciona. Abrimos otro Visual studio o ejecutamos el ejecutable que está en la carpeta bindebug o binrelease (si compilamos en modo release) En la aplicación Windows Forms agregamos la dll de la aplicación del servicio. En la apliación ponemos servicehost(typeof(Service1) new uri(http:// ) El App.config de la aplicación es una copia del web.config del servicio. Se puede ver el binding Service1 es la clase que implementa el servicio.
  • Manejo de errores Para gestionar los errores usaremos los try y catch. - Salta la excepción y la capturamos, la empaquetamos y se la enviamos al cliente. - Si es un error de funcionamiento (división por cero…) se lo enviamos al cliente, sino lo tratará el servicio. - La comunicación es por SOAP y a través del contrato. Para manejar errores, tenemos la clase FaultException y FaultException<T> (la segunda es fuertemente tipada) y las dos pertenecen a la clase ServiceHost El atributo FaultContract lo colocaremos encima de cualquier método que pueda lanzar excepciones. Ejemplo: namespace GestionErrores { // NOTE: If you change the interface name "IService1" here, you must also update the reference to "IService1" in Web.config. [ServiceContract] public interface IService1 { [OperationContract] [FaultContract(typeof(MiError))] //creamos la excepción y el tipo que va a devolver
  • string GetData(int value); // TODO: Add your service operations here } // Use a data contract as illustrated in the sample below to add composite types to service operations. [DataContract] public class MiError { private string _reason; [DataMember] public string Reason { get { return _reason; } //Esto es lo mismo que el get; y set; set { _reason = value; } } [DataMember] public string Message { get; set; } } }
  • Podemos poner parámetros… (de momento no ponemos)
  • public class Service1 : IService1 { public string GetData(int value) { try { int i = 0; int j = 4; int z = j / i; return string.Format("You entered: {0}", value); } catch (Exception e) { MiError elError = new MiError(); //Instancia del contrato de datos pero sólo de la clase error elError.Reason = "Algún error " + e.Message.ToString(); //relennamos el objeto de la clase elError.Message = e.Message.ToString(); FaultReason fr = new FaultReason(e.Message.ToString()); //le damos una razón al encapsulado // si no lo ponemos te compila pero al ejecutar te da un error "no tiene una razón asociada". throw new FaultException<MiError>(elError, fr); // Esto es fuertemente tipada por poner entre corchetes la clase // si no lo ponemos el cliente lo tratará con la clase FaultException (no con nuestra clase) //throw new FaultException(fr); } }
  • Si le damos a depurar Y vemos el WSDL, abajo se ve la excepción que puede dar. (desde el fichero svc) ComunicationException, da más información de qué error ha dado la conexión (Endpointnot found, ProtocolException, TimeoutException, CommunicationObjectFultedException), esta clase deriva de Exception Como tratarlo: Creamos un proyecto dentro de la misma solución con un botón y una label. using System.ServiceModel; //Añadimos la referencia a esta clase para usar FaultException namespace WindowsFormsApplication1 { public partial class Form1 : Form { public Form1() { InitializeComponent(); } private void button1_Click(object sender, EventArgs e)
  • { Proxy.Service1Client prx = new WindowsFormsApplication1.Proxy.Service1Client(); try { label1.Text = prx.GetData(2); } catch (FaultException<Proxy.MiError> err) { label1.Text = err.Detail.Message.ToString(); } } } } ::::::::::::::::::::::::: Vamos a hacer la práctica de llamar al servicio arrancado por la otra aplicación. Ejecutamos el exe de la aplicación:
  • Tenemos que hacer una referencia al servicio, para ello vemos la dirección donde está alojado el servicio: Y añadimos la referencia al servicio (sin el ¿wsdl final) En el click ponemos: private void button1_Click(object sender, EventArgs e) { Proxy.Service1Client pr = new Proxy.Service1Client(); label1.Text = pr.NoChar(textBox1.Text).ToString(); } } Si lo probamos ahora funciona pero no sabemos si está funcionando por el IIS o por la otra aplicación. Paramos el IIS y lo probamos.
  • Instancias y Concurrencia Instancias: Un hilo (cada vez que llamamos a una clase) Concurrencia: Varios hilos ejecutándose a la vez Instancias: - PerCall: UN hilo por cada llamada. (mucha carga) - PerSession: un hilo por cada coiente (por defecto la sesión dura 10 min) pero es configurable. (por defecto) cada vez que instanciamos a la clase proxy se levanta un hilo. - Single: Una única instancia que se queda esperando. (poca carga pero menos rendimiento (se encolan). En función de las necesidades se usan unas u otras. TimeOuts Concurrencia Memoria y recursos Ciclo de vida PerCall Ok Ok Ok No PerSession No/10 min. No/menos No/caso medio Ok Single No No No Ok En el systembehaviour podemos poner muchos parámetros, de momento sólo el PerCall:
  • Copiamos este código y levantamos el servicio: [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)] public class Service1 : IService1 { public string GetData(int value) { System.Threading.Thread.Sleep(10000); //Se podría poner el using System.Threading al principio (mejor) return DateTime.Now.ToString(); } } Si cambiamos el namespace hay que cambiar también el Service1.svc (botón derecho abrir con xml) y cambiar por: <%@ ServiceHost Language="C#" Debug="true" Service="EjemploGestionInstancias.Service1" CodeBehind="Service1.svc.cs" %> (Aun así no ha funcionado bien) (de momento no cambiamos el nombre del nameespace por defecto. Concurrencia del servicio: - Single: (por defecto)
  • o una única petición se activa siempre o Límite de peticiones por InstanceContextMode o No produce interbloqueo. - Reentrant: o Semisegura (puede provocar interbloqueo) - Multiple: o No segura (se crea un hilo por cada recurso al que quiero acceder) o Multiples peticiones se activan en el acto. o Se puede configurar en el web.config: Throtting (behavior) Práctica 2 Crear un servicio y cambiar el endpoint wshttpBinding por el basichttpBin Creamos un proyecto Consumobasichttpbinding (permite compatibilidad con los antiguos servicios Web) Pegamos un botón y una label. Añadimos una referencia Web al servicio que ya está alojado (lo que había en la URI) private void button1_Click(object sender, EventArgs e) { Proxy.Service1Client pr = new ConsumoBasichttpBinding.Proxy.Service1Client(); label1.Text = pr.NoChar("porpoer").ToString(); } Ahora vamos a hacer algo para que no funcione: Vamos a utilizar una herramienta: Tools-WCF Service Configurator Editor
  • Copiamos el contrato
  • Creamos uno nuevo: Y borramos el que había El nuevo es basic…. Y el antiguo era wshttpbi… Ahora no funcionaría: abrimos el app.config Creamos un nuevo endpoint
  • Faltaría copiar el contrato que había en el otro y borrar el endpoint anterior
  • RESUMEN Y MEJORAS DE ACUTACIÓN Instancias Per call… Resumen gráfico de Gestión de instancias y concurrencia. Persession . una por cada cliente. Pero call. una montón de instancias por cada una de las llamadas (tendrías un solo cliente que llama a tres métodos distintos de un mismo servicios) Single-una única instancia que atiende en cola. Atiende una y la siguiente espera. .Especificar el modo de concurrencia: el atributo SERVICE Behavio. Gestión de hilos sobre las instancias Multiple-muchos hilos concurrentes que tienen problemas a acceder a recursos que se gestionan a través del servicio. .SOLUCIÓN : CALIDAD DEL SERVICIO. .Con mucho hardware no habría problema con acceso a los recursos. Con hardaware limitado pues deberemos valorar para poder dar la mejor gestión a los clientes. Throtting (behavior)((((RECUADRO ANTERIOR))))…
  • En el web.config, abajo del todo ((((Saber cómo se hace .. En nuestro servicio no es necesario, ya que estamos “nosotros sólos en nuestra máquina”)))) Aquí pondremos el máximo de conexiones máximo de llamadas, sesiones… Le estás diciendo cual es el comportamiento que tendrá este servicio a la hora de generar instancias. Se
  • consigue que la carga del proceso sea menor…Es una forma de ir mejorando los redimientos a partir de nuestro hardware. En los cpd´s tenemos hardware. Los telecos han inventado poner varios servidores que escuchen servidores. Tenemos configuración “balance de carga” NLB. El proxy va balanceando las peticiones. Tenemos instancias concurrentes. En este escenario debe funcionar deforma óptima como si funcionásemos con un solo servidor. Hay que reducir la afinidad con el servidor. El usuario debe funcionar como si sólo tiene un servidor, nuestra instancia puede estar en cualquiera de los servidores pero debe “parecer” que sólo está en uno. Al final son distintas peticiones que se guardan las sesiones en bases de datos. Nosotros nos evadimos del tema hardware y guardamos sesiones en bases de datos. La sesión en base de datos se elimina todos los datos una vez que se salga de dicha sesión, no almacena ningún datos. Esos ayuda a la ligereza de los datos en bases de datos. .Para tolerancia a fallos-discos espejos. Servidores replicándose y cuando falla se recupera del backup .La señalización en XML lo señaliza en un buffer. Tiene que leerlo todo para luego poder transmitirlo . .Gran sobrecarga de trabajo en serialización. .El problema de los datos binarios en SOAP. A ESTOS TENEMOS DOS SOLUCIONES: MTOM-mecanismo de optimización de transferencia de mensajes. En la parte queña de xml que sea la responsable. Las partes bianarias irán en pequeños mensajes con tipo mime que iremos lanzando. (ver cuadro) En el xml tenemos a su vez referencia a esos archivos tipo mime. Ventajas;: optimiza con respecto a sopa en tratamiento de los binarios. Como son pequeños mensajes no hace falta que se haya recibido todo para empezar a deserializar. Configuración de los tamañaos una ventaja. Desventaja- División de mensajes en tipo mimees Referencia los mensajes binarios desde XML Procesamiento de construir y reconstruir mensajes.
  • STREAMING CARACTERÍSTICAS Envío continuo Recepción antes de fin envío VENTAJAS Mejoras rendimiento Envío binario puto INCONVENIENTES Menos interoperabilidad. Sólo lo podrías leer con binarios. Cuando se pide algún dato es insconsistente. DEMO:: Ir a interface y copias esto:
  • Una vez que está… donde tengamos el archivo de texto se copia en la ruta original del proyectos y en show files se actualiza el estado de los archivos en dicho proyecto. Actualizarías el estado del archivo para que esté actualizado… la ruta sería
  • AÑADIMOS a mano: using System. IO;
  • Finalmente se compila y hala, compilado queda ¡!!.
  • Resumen: Si hay dos servidores de aplicaciones y la conexión es PerSesion ha que guardar la sesión en la BBDD para que no funcione aunque luego nos conectemos a otro servidor. MTOM: Tenemos una cabecera XML y luego tipos MIME con los binarios. - Ventajas: tratamiento optimizado. - Desventaja: División de mensaje en fragmentos que hay que recomponer. STREAMING: Flujo de bites desde el servidor al cliente: - Ventajas: Optimo al envío (no es necesario que esté serializado para enviarlo) - Práctica: Hay que cambiar el app.config para que admita más bytes enviados y recibidos, le cambiamos también un endpoint por basichttpBinding¿? Ya está hecho el envío del fichero faltaría cambiarlo por basichttpBinding, para ello entrar en Tools y el WCF configuration (para que luego aparezca en el menú contextual). Luego editamos con el WCF conf. El fichero y lo cambiamos por basic… y luego en el fichero añadimos el endpoint¿? Seguridad Puntos clave: - Autenticación: Certificados de seguridad o Por ejemplo el X509. o Cifrados: Existe la clave pública y la privada. Si sólo yo lo puedo enviar utilizo la privada. Si quiero que B pueda descifrarlo, lo envío con su clave pública. (algoritmo asimétrico). Cuando llegue, sé que sólo A lo ha podido enviar y sólo B lo va a poder leer. Esto es muy costoso.  Mixto: Me pongo en contacto con el servidor y le pido una clave y durante esa sesión uso esa clave. Es óptimo pero menos seguro (algoritmo simétrico, usamos la misma clave).  Lo que se hace es encriptar el envío de la clave con la clave privada de A y con la pública de B. B desencripta esa clave y envía encriptado el mensaje de aceptación (Ack)
  • - Autorización: Hay distintos proveedores de autorización (Windows rols, ASP.NET rol…, o personalizado): o Roles Windows (AD) o Roles ASP.NET o Custom o Basado en peticiones (WCF)  Modelo basado en roles de “grado fino” (un usuario puede tener varios roles asignados)  Bajo clases WCF (ClientSet)  Permite denegar peticiones particulares aunque este en un grupo.  Separación elementos de la autenticación. Aunque el usuario pueda autentificarse tú le puedes cerrar la sesión. - Integridad: depende de los protocolos de transporte. (enlazado con la confidencialidad) - Confidencialidad : https: Cuando creamos el proxy tenemos clientcredentials con . saldrá el username y el password. Intercambio de credenciales Se puede establecer a nivel de transporte o a nivel de mensaje Tipo de credenciales: None Basic Digest NTLM (es la identificación de Windows NT) (en SQL también se utiliza) (también tiene que ver con el Active directory) Windows : con el usuario de Windows Certificado Se puede establecer en configuración o en código: En configuración: Ventajas:
  • Dinámico (XML que se puede configurar) Desventajas: Lento (tenemos que acceder al XML) Poco dinamismo ¿? Programáticamente: Ventajas Mas dinamismo, dentro del mismo programa podemos usar el mismo servicio con distintas credenciales Tiempo de ejecución Desventajas: Credenciales compiladas en código Una vez compiladas no se pueden cambiar Se puede mejorar esto guardando el usuario y la clave en el config en la sección <AppSetting> <add Key=””valor””> Se podría guardar cifrado para que no quede en un fichero plano. Transacciones Propiedades: - Atómica: o se ejecuta todo o nada - Consistencia: Estado inicial y final consistentes - Aislados: Los estados intermedios ocultos a otras operaciones (unas no se deben afectar a otras) - Durabilidad: Persistencia (lo que sería un COMMIT) Transacciones distribuidas: - Propagación de acciones entre ordenadores (cuando se ponga en producción probablemente el servidor no sea el mismo que el de la aplicación, BBDD, etc… - Propagación de COMMIT y ABORT (si en el cliente hago un commit se tiene que llevar al servidor. - MSDTC: controlador de transacciones distribuidas (a veces está deshabilitado y hay que habilitarlo) Distribuirlas manualmente (no lo vamos a ver) sería crear la clase cliente transaccional y pasar al servicio el abort… etc… En panel de control . servicios de componentes – Coordinador de transacciones. Con el botón derecho sacamos el MSDTC, también está el COM+ (sin él tampoco funcionan las transacciones) Todos los binding no son transaccionales (p ej el basichttp… no es transaccional), los más habituales son: WSHttpBinding, NetTcpBinding
  • Ejemplo: Abrimos el ejemplo transacciones.sln y vemos el web.config Aquí configuramos que el servicio admite transacciones <bindings> <wsHttpBinding> <binding name="NewBinding0" transactionFlow="true"> <security> <transport> <extendedProtectionPolicy policyEnforcement="Never" /> </transport> </security> </binding> </wsHttpBinding> </bindings> El atributo TransaccionalFlow puede ser: - Notallowed - Allowed - Mandatory En código veríamos que en la interfaz encima del método ponemos: (para decir que ese método permite transacciones [TransactionFlow(TransactionFlowOption.Allowed)] string GetData(int value); Con el atributo Service behaviour definimos el nivel de aislamiento: Chaos: Los cambios pendientes no se pueden sobreescribir… (ver doc) Serializable: Lectura, sin modificación y añadir nuevos datos RepeatableRead Lectura y adición sin modificación Snapshot se pueden leer los datos variables, antes de modificar comprueba si ha sido modificado por otra transacción (es el más complejo pero el más completo) Unspecified (no se usa) En la clase de servicio encima decimos el comportamiento [ServiceBehavior(TransactionAutoCompleteOnSessionClose = true, TransactionIsolationLevel = System.Transactions.IsolationLevel.ReadCommitted,TransactionTimeout="0 .01:00:00")] public class Service1 : IService1 el 0.01 significa 10 minutos ¿? Si ponemos una coma detrás vemos los posible atributos:
  • Compilamos: REBUID Primero hay que lanzar la instancia de transacciones (daba un error en un línea de transaction… y la borramos. Volvemos a lanzar la instancia y ya aparece una página web. En el cliente para que funcione tenemos que borrar del app.config todo lo que hay dentro del Servicemodel y damos con el botón derecho en el proxy y actualizar y se vuelve a generar todo lo que había en el app.config al ejecutar la instancia ya funciona, pide un número. Otro ejemplo: Abrimos la práctica de Center Service Tenemos un acceso a una BBDD SQL bibliotecaDB.mdf que tiene una tabla : Haciendo doble click en la BBDD vemos las tablas Creamos un GetPedido GetTodos los libros En la clase de servicio creamos una sentencia linqueue Se ha añadido una excepción para que si hay menos cantidad de un error. En el cliente cuando hago un pedido da el precio y decrementa el stock de libros.