<<Lo mejor que he visto hasta ahora>>

Lista de 11  impresionante de TIPS para usar WCF.

Cosas cool:

• El canal wsdualhttp es de jugete, confirmado
• No usar mas XSD para validación de mensajes.
• Una recomnedación muy buena es tener una interfaz de admisitarción común para los servicios.

Expositor :CraigMcMurty, Technical Evangelist

1.- Validación de mensajes.

0.-no validar mensajes con XSD

a.- la performance es mala.

b.- Dentro del canal se debe poner la validación.

c.- también se puede poner en el Message Inspector

d.- Mejor desempeño si se usan clases tipeadas, en el parameter inspector se puede validar los valores.

e.- XSD no tiene buen soporte de herramientas.

 

2.- SOAP FAULT

a.- Existe Fault Contract para falla en la estructura del mensaje.

b.- Fault Execption se ve en el proxy generado, pero no en wsdl.

 

3.- Traza a tarves de varios HOPS de servicios TRracing

a.- WCF puede hacer traza nativamente, con nivel de criticidad

b.- Se puede definir donde poner la traza, en que archivo.

c.- Tools traceview apoya el estudio de los LOG, aunque sean de diferentes puntos.

 

3.- ¿cómo puedo impersonar y mover las credenciales al servidor? Protocol credential

a.- Impesonalisation usando windows identity usando Kerberos/NTNL, en el binding configuration se puede habilitar la impersonalización por configuración.

b.- En el lado del servicio, se debe agregar en el servicio y en el metodo un atributo para permitir la impersonalisación.

c.- ¿Qupé pasa sin no es windows identity?

c.1.- Se debe usar STS, enviar el token y es complicado. En el largo plazo es mejor!!

 

4.- Buenas prácticas para hacer llamadas en el mismo proceso

a.- Esto no es un problema de computación distribuida.

b.- WCF no es para esto.

 

5.- Las mejores prácticas con equivalentes a NO HAGA….

a.- Ojo con los pilotos, no son una solución final J

 

6.- Addresses

a.- Cuando tenga su propio host defina la dirección base pero uso para el endopoint una dirección relativa.

b.- El binding delendpoint pueda cambiar sion cambiar la direccion base.

 

7.- Binding

a.- WSDUALHTTP: no aplica con firewall, NATs y IPv4. Es para demos, pero no tiene aplicaciones prácticas en el real WORLD. En IPV6 será posible.

b.- wsHTTP desabilite los protocolos que no usará.

b.1.- WS-I no está garantizando la intorepabilidad, por ejemplo con BEA.

d.- QUEUED:

d.1.- tiene el limite de tamaño de 4 MB.

d.2.- NO tiene remote recive.

f.- NetTcPBinding: para WCF-TO-WCF

g.- netPeerTcpBinding: solo es para P2P application.

h.- Streaming: se usa para archivos, por ejemplo musica.

h.1.- No está seguro para mandar grandes mensajes.

 

8.- Contratos

a.- ¿Qué pasa con los valores por defecto? Son diferentes de los defectos de ASMX

b.- Solo use tipos de datos que pueden ser resueltos por XSD. No mande DATASET aunque sean tipeados. No interoperan en la práctica.

c.- ContractFirst es una forma de diseñar, ojo con los atributos XML porque no pueden ser serializados en los contratos WCF, solo se deben usar elementos en XML.

d.- Uso de clases parciales (public partial class myDataContract) para los contratos. Los datos en una parte los metodos en otra parcial class. Así es fácil leer como es el contrato.

e.- sobre propiedades publicas y privadas: no hay diferencia en la serialización, si se usa serialización XML deben ser públicos los miembros para que sean considerados.

f.- La sección Header es para datos de protocolo no de negocio. MessageContract da acceso a todo el mensaje. DataContract solo al body del mensaje.

g.- Proveer un FaultContract para cada OperationContract.

h.- Proveer una operación por defecto: Action=”*”.

i.- Trate primero que la comunicación se asíncrona, si no es posible use sync.

j.- La interfaz de administración. Es una interfaz de consulta sobre el estado de la aplicación. Muy útil para saber que está pasando con la operación del servicio.

 

9.- Service Implementation

a.- Para elegir un WebHosting se debe tener en cuenta:

a.1.- Se pueden subir nuevos built?

a.2.- Provee seguridad seria.

b.- cuando uno tiene el hosting, llame expicitamente Close() para mejorar el desempeño.

c.- Implemente los servicios en una DLL independiente. Para poder tener un debugg decente.

d.- Para reducir la latencia y mejorar el desempeño haga:

d.1.- IntanceContextMode=Single.

d.2.- ConcurrencyMode=Multiple.

e.- Para mantener estado: use los mensajes, guarde los datos,

f.- No guarde estados, si lo hace que sea compatrible con ASP.NET

g.- ServiceAuthorizationManagerTypes es el modelo ideal.

g.1.- Es mas general, confiable pero considere el motor de reglas de WF para implemenatar)

 

10.- Client Implementation

a.- Siempre use programación asíncrona.

b.- Reduzca la latencia de la primera llamada usando el método OPen().

c.- Siempre llame el método Close(). Esto acelara el colector de basura.

 

11.- Managment

a.- Use WMI. Turn ON.

b.- Haga un model de health consistente,

b.1.- Deje contadores.

b.2.- Use Event Log.

b.3.- Tenga una interfaz de administración