Un Aktiv en clase de Web Service.

1. 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.

2. 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

3. 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

4. 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.

5. 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

6. 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);
}

7. 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:

8. 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

9. 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

10. Añadimos la referencia al servicio:

11. 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.

12. 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

13. 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)

14. 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

15. Aquí veremos la dirección del servicio al que podemos llamar desde nuevas aplicaciones (la
dirección hasta el .svc

16. 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

17. 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

18. 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

19. 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:

20. 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;

21. }
// 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

22. 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(:

23. 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.

24. 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

25. 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;
}
}
}

26. Podemos poner parámetros… (de momento no ponemos)

27. 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);
}
}

28. 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)

29. {
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:

30. 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.

31. 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:

32. 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)

33. 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

35. Copiamos el contrato

36. 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

37. Faltaría copiar el contrato que había en el otro y borrar el endpoint anterior

38. 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))))…

39. 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

40. 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.

41. 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:

42. 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

43. AÑADIMOS a mano:
using System. IO;

44. Finalmente se compila y hala, compilado queda ¡!!.

45. 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)

46. - 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:

47. 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

48. 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:

49. 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.