WCF opiniones...

Compact WCF Ten Commandments # .NET Compact Framework 3.5

2007-09-14T08:09:00.000-07:00

Compact WCF was born from E-Mail transport capabilities. Read and understand the story of "Lunch Launcher"
Compact WCF is a subset of WCF Framework.
Compact WCF only consume, don't host WCF Service.
Forget Contracts. You are managing messages, so...
... be familiarized with Channel Factories and XmlSerializerWrapper.
Compact WCF don't support MSMQ, TCP o others transports. Http/s and E-Mail transports bindings do.
Forget transfer a large amount of data into a message, discard stream mode, is not available. "Buffer" it into your head.
Compact WCF supports a subset* of WS_Security and WS_Addresing. [* -> only Basic256Rsa15.]
Make Microsoft Exchange MVP o expert friend. Keep him/her close to you.
Think Mobile.

Service Throttling

2007-03-20T04:21:00.000-07:00

Throttling viene de throttle, y este termino sólo lo había utilizado en aviación "move throttle from idle,..." y se refería a la palanca de gases de los reactores modernos. Pero que carajo significa en WCF??

Throttling es una técnica que permite la restricción de clientes de un servicio WCF. Ésta se aplica al Servicio y todos sus EndPoints. Los tres parámetros que controla son:

Concurrencia máxima de sesiones
Concurrencia máxima de llamadas
Concurrencia máxima de instancias

Pese a que se asigna al tipo de Servicio ésta, al igual que otras, es un aspecto del hosting, con lo que deberemos indicar los valores en el .config del proyecto que lo hospeda. Un ejemplo:

[serviceBehaviors
[behavior name = "MiServicio"
[service throttling maxConcurrentsSessions = "10"
maxConcurrentsCalls = "10"
maxConcurrentsInstances = "5" \]
\]
\]

NOTA: He utilizado brackets (paréntesis) en lugar de <>

Clientes VB6

2007-03-19T04:52:00.000-07:00

Por lo que he podido ver la interoperabilidad de clientes no WCF está bastante presente sin embargo con algunas conotaciones, ya sea el cliente Java, COM o VC++.

En el caso de Visual Basic, por lo que he podido ver, existen tres escenarios en función del Runtime instalado. Así, si el cliente posee .NET Framework 3.0, la opción más lógica es la creación de un ensamblado COM Interop, que contenga el proxy al WCF Service. Es decir, el cliente que, normalmente, generamos con Svcutil.exe, lo exponemos a COM y exportamos la biblioteca de tipos para que sea referenciada por un proyecto Visual Basic 6.0. En el segundo caso, el cliente tiene .NET Framework 2.0. La alternativa anteriormente comentada no es válida así que podemos generar, el lugar de un proxy WCF, un proxy ASMX. De las misma forma pasamos en proxy a COM Interop, exportamos la biblioteca de tipos y referenciamos o instanciamos desde VB6. La última, en la que no tenemos el CLR de .NET instalado, podemos utilizar SOAP. Windows XP viene con las biliotecas

Escenarios de seguridad en WCF: A nivel de Mensaje

2007-03-08T00:19:00.000-08:00

¿Transporte o Menaje? Bien, según el escenario, aunque ahora no hablaré de ello (quizás otro post). Ante la posibilidad de implantación de servicios desarrollados con WCF, se presentan varios escenarios dónde la utilización de los mismo vienen, sino determinada, sí influenciada por su política de seguridad.

Modos de seguridad hay 5 [None, Transport, Message, Both, TransportWithMessageCredentials, TransportCredential Only], si quereis ampliar información mirar aqui.

Message Security with Username Client

Ante este contexto explicaré tres posible modos de autenticación UserName. Primeramente saber que en los tres modos de autenticación en el Servidor debe existir un certificado X509 para que el cliente pueda constatar la autenticidad del servicio. Si quereis más info de como crearlo mirar aqui.

En el intercambio inicial desde una llamada del cliente los datos en formato binario son trasportados mediante la especificación WS-Trust (véase TLS Negotiation). Una vez el servicio ha sido autenticado se establece un contexto de seguridad compartido [Shared security context].

Los mensajes, por defecto, están encriptados y firmados (véase ProtectionLevel ) y són transportados bajo dicho contexto de seguridad. La peculiaridad de este escenario és que el cliente es autenticado mediante un User y un Password. El tipo de enlace es wsHttpBinding, el transporte HTTP.

Modos de Autenticación:

* Utilizando autenticación por Windows: El tipo de credencial por UserName requiere de un valor User y otro Password que se deberán especificar a la hora de llamar desde el cliente mediante la propiedad clienteproxy.ClientCredentials.UserName.User o Password. Bajo el escenario en que nos encontramos, si no se especifica el tipo concreto de autenticación será, por defecto, autenticación Windows. Es decir que si en la llamada pasamos en User algo tal que 'Dominio\Usuario' con el respectivo password, la autenticación, con el permiso del controlador de dominio, se validará.

* Utilizando autenticación MemberShip: Pues como si se tratara de un site en ASP.NET podemos utilizar la misma funcionalidad. De entrada se me ocurre como ideal si se va a consumir por Internet y/o se va a utilizar la misma autenticación de nuestra site web o Intranet. Sin embargo, debemos indicar en el comportamiento del servicio (ServiceBehaviors\Behavior\ServiceCredentials) del archivo de configuración el tag siguiente:

[userNameAuthentication="MembershipProvider" membershipProviderName="SqlMembershipProvider"]

En este punto los valores que debemos pasar como User y Password són los que tenemos asignados dentro de Membership. Un buen documento que profundiza más es el siguiente.

* Otro escenario, quizás algo menos útil [aparentemente, opinión personal], pero mucho más flexible es mediante la autenticación parametrizada o customizada. Esto es, añadiendo una clase a nuestro Proyecto Servicio, que herede de UserNamePasswordValidator y sobreescribiendo (override) el método Validate, cuyos parámetros son user y password del tipo string, podremos manipularlos de la forma que queramos. Para ello el tag a añadir es:

[usernameauthentication="Custom" membershipProviderName="mypoject.myservice.CustomUserNameValidator, Project1"]

Dónde indicamos la clase que manejará la autenticación (CustomUserNameValidator), que hereda de UserNamePasswordValidator, y que está en el ensamblado (proyecto) Project1.

Ejemplo:

public class CustomUserNameValidator : UserNamePasswordValidator {
public override void Validate(string userName, string password) {
if (userName != "miusuario" password != "mipwd") {
throw new SecurityTokenException("Usuario/Contraseña incorrecta");
}
}
}

Excepciones con FaultException

2007-03-06T05:07:00.000-08:00

Cuando planteas la creación de un sistema bajo Windows Communication Foundation, una capítulo entero, lo inviertes en la estrategia de manejo de excepciones. No resulta complejo entender que una excepción se transmite como una "avería" dentro de SOAP.

Durante la captación de información previa a tomar una decisión me encontré con enlaces interesantes, como este de, como no, Rodrigo Corral, o varios documentos explicativos muy útiles como éste o éste, pero sin embargo, desde un punto de vista muy elemental. Los ejemplos del SDK de Windows son, también, de ayuda aunque pasan, también, de escenarios elementales a escenarios muy complejos (o al menos eso me ha parecido a mí).

Una de las batallas más arduas en la que me he visto envuelto a sido una excepción, muy simpática, pero que me ha llevado de cabeza FaultException was unhandled by usercode. En una solución, he puesto todos los proyectos, desde la definición del servidor hasta la implementación del mismo desde el Cliente. Cuando se generaba una excepción en el servicio, ésta no era controlada por try...catch desde el cliente; bueno, a ver, si que lo hacía pero al segundo intento. Esto es, se produce un error en servidor, se para la ejecución, vuelvo a ejecutar con F5 y el cliente obtenía la excepción como era de esperar.

Por si os pasa alguna vez, me han ayudado mucho estos dos enlaces de los foros de MSDN. En concreto éste. (el otro es éste). Sinceramente no me acaba de convencer, pero es lo que hay, almenos por el momento hasta que alguien diga exactamente el por qué.

Ahora me toca probar la capacidad del Enterprise Library en el control de errores, ya os informo.

Technorati

2007-03-05T04:48:00.000-08:00

Technorati Profile