Hace poco, a través del site de Alejandro Mezcua, encontré un post introductorio acerca de la utilización de WCF desde .NET CF 3.5. Ahora, Mark Prentice, autor de los post, muestra una de las utilizaciones que más beneficios va a aportar (creo yo) en entornos móviles, enlaces WCF a través de Exchange.
La idea nació dentro del equipo de desarrollo de .NET CF, concretamente de Mike Zintel, y fue Roman Batoukov quién a través de un post imprescindible, explicaba cómo desde entornos móviles podían sacar el máximo provecho WCF, ¿como? pues a través de correos electrónicos...
Si estais interesados sobre el tema os recomiendo primero, la teoria, de Roman y luego la puesta en marcha (practica) de Mark. El resultado... espectacular.
Si alguien quiere compartir su experiencia, por favor, dejad un comentario; quiero comprobar si os quedais tan impresionados como yo...
jueves, abril 26, 2007
miércoles, abril 25, 2007
Se acercan MEDC (Las Vegas y Berlín)
Otro año más se celebra el Microsoft Mobile & Embedded Developer Conference en Las Vegas dónde las estrellas serán .NET CF 3.5 y Windows Mobile 6. Para la edición de Europa, este año pasa a celebrarse en Berlín.
Otro año más, también, que no puedo ir y me voy a quedar con las ganas. Si alguién va que lo disfrute!!!
Otro año más, también, que no puedo ir y me voy a quedar con las ganas. Si alguién va que lo disfrute!!!
lunes, abril 16, 2007
Taggeado!!
Pues si, mi buena amiga Fabiana, me ha taggeado. Confesaré 5 cosas sobre mí que normalmente no cuento. Me apunto a esta estupidez :-)
- Cuando sea grande quiero ser piloto de avión y caminar por los aeropuertos con las espaldas anchas y mis 'lupas' RayBan, que por cierto ya las tengo aunque solo me las pongo en el coche. Soy un chiflado del Flight Simulator.
- Estoy 'chiflao' por el cava catalán. Mis preferidos son el Kripta d'Agustí Torelló, Reserva de la Familia de Juvé i Camps, Reserva de Sumarroca, 'er' de Cristina Colomer Bernat, Celler Batlle de Gramona y el Gran Reserva de Robert J.Mur, entre otros...
- Confieso que siento una enorme admiración por Juan José Moreno Cuenca, del cual tengo todas las películas que hablan de su vida, así como el libro autobiográfico que he leído ya dos veces.
- En mi coche tengo una pegatina/retrato de José Monge Cruz. Para quién le guste el flamenco, estará conmigo, sobran las palabras.
- Cuando era pequeño gané el campeonato de catalunya de cross y fuí subcampeón varias veces en varias categorias. Tenía una prometedora carrera en el mundo del atletismo que se truncó, para mi desgracia. Posteriormente pasé a correr delante de la polícia...
Podría profundizar en alguna de ellas, pero tampoco hay que pasarse ¿¿no??
Ah! se me olvidaba, voy a taggear (o como se llame) a Marino Posadas, Santi Balboa.
Windows Mobile 6 (SDK y API obsoletas)
Ya se ha publicado el SDK de Windows Mobile 6, tanto para la versión Professional (WM 6 inc. Phone Edition) como para la Standard (WM6 Smartphone).
Microsoft ha modificado los nombres de las categorias del nuevo sistema operativo de la siguiente manera:
Microsoft ha modificado los nombres de las categorias del nuevo sistema operativo de la siguiente manera:
- Windows Mobile (Smartphone) = Windows Mobile Standard
- Windows Mobile (Pocket PC) = Windows Mobile Classic
- Windows Mobile (Pocket PC Phone Edition) = Windows Mobile Professional
De esta forma debemos indentificar los nuevos nombres la a la hora de crear un nuevo proyecto (Tipo de Proyecto) e Imágenes del Emulador.
Por otro lado también se ha publicado las API que dejan de ser funcionales en Windows Mobile 6. La verdad es que la lista es larga, así que os invito a echar un vistazo en Channel 9.
Service Throttling
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:
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 <>
miércoles, abril 11, 2007
CATdotNET.org
Hace poco más de un par de meses me reuní con Lleonard del Río, socio-fundador de Raona, ya que nos rondaba por la cabeza la creación de un grupo de usuarios que englobara tanto a profesionales, como estudiantes o simples entusiasta de la tecnología .NET. A partir de entonces y con la inestimable colaboración y ayuda de Diégo Gómez, empezó a tomar forma lo que ahora es CATdotNET.org, un grupo de usuarios de .NET para la Catalunya central, en el que pretendemos ofrecer un marco de colaboración a través de nuestra web, aún en construcción, con reuniones periódicas entre Igualada y Manresa.
CORRECCIÓN:
A principios del mes de Mayo, convocaremos la primera reunión y poder ofrecer un par de charlas sobre .NET. La fecha y la hora así como el temario de las charlas no estan concretadas por tanto, en cuanto se hagan oficiales las podreis encontrar en la Web.
Asi mismo, si estais interesados en obtener más información, colaborar o cualquier otra sugerenicia u opinión, no dudeis en contactarnos.
CORRECCIÓN:
A principios del mes de Mayo, convocaremos la primera reunión y poder ofrecer un par de charlas sobre .NET. La fecha y la hora así como el temario de las charlas no estan concretadas por tanto, en cuanto se hagan oficiales las podreis encontrar en la Web.
Asi mismo, si estais interesados en obtener más información, colaborar o cualquier otra sugerenicia u opinión, no dudeis en contactarnos.
martes, abril 10, 2007
Smart Client Software Factory, excelente!!
He estado 'trasteando' con la versión Alpha 7 de Abril del Smart Client Guidance que podeis encontrar en CodePlex. Lo que más me ha llamado la atención és la posibilidad de utilizar el Connection Manager, que tantas veces he necesitado desde las aplicaciones en Windows Mobile, ahora para Windows XP/Vista y con resultados sorprendentes y de forma sencilla...
Smart Client Software Factory forma parte de Smart Client Guidance de patterns and practices, en el que también engloba Mobile Client Software Factory (del cual dedicaré una serie de post). Además del ConnectionManager también encontraremos ejemplos de extensibilidad de WPF para nuestras aplicaciones Windows, así como todo tipo de ejemplos fundamentados en el 'padre' de SCSF, Composite UI Application Block, un marco de trabajo basado en .NET 2.0 y que permite el desarrollo de UI ricas, flexibles, extensibles y "fáciles" de desarrollar.
En fín, Smart Client Guidance es toda una herramienta en la línia de Enterprise Library 2.0, al principio asusto pero luego disfrutas a lo grande!!
Smart Client Software Factory forma parte de Smart Client Guidance de patterns and practices, en el que también engloba Mobile Client Software Factory (del cual dedicaré una serie de post). Además del ConnectionManager también encontraremos ejemplos de extensibilidad de WPF para nuestras aplicaciones Windows, así como todo tipo de ejemplos fundamentados en el 'padre' de SCSF, Composite UI Application Block, un marco de trabajo basado en .NET 2.0 y que permite el desarrollo de UI ricas, flexibles, extensibles y "fáciles" de desarrollar.
En fín, Smart Client Guidance es toda una herramienta en la línia de Enterprise Library 2.0, al principio asusto pero luego disfrutas a lo grande!!
lunes, abril 09, 2007
Cliente VB6
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
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
martes, abril 03, 2007
Escenarios de seguridad en WCF: A nivel de Mensaje
¿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");
}
}
}
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");
}
}
}
lunes, abril 02, 2007
Excepciones en WCF I (FaultException)
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.
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.
Suscribirse a:
Entradas (Atom)
