06.27.08
Posted in WCF at 7:55 am by Miguel
“ServiceDebug” es el tag que debe añadirse a la conducta asociada a nuestro servicio de WCF para que publique la descripción del error a los clientes, en el caso de que se produzca algún problema a la hora de consumir un servicio.
<system.serviceModel>
<services>
<service name=”WCFPolimorfismo.MiServicio” behaviorConfiguration=”miConducta”>
<endpoint address=”" binding=”basicHttpBinding” contract=”WCFPolimorfismo.IMiServicio”></endpoint>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name=”miConducta”>
<serviceMetadata httpGetEnabled=”true”/>
<serviceDebug includeExceptionDetailInFaults=”true”/>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
Saludos.
Miguel.
Permalink
06.26.08
Posted in WCF at 6:13 pm by Miguel
Siguiendo con WCF, a continuación os adjunto otra evolución del proyecto de servicios web polimórficos donde se puede observar la creación de un enumerador “PaisEnum” que es visible también desde el cliente consumidor gracias a aplicar en conjunto las etiquetas “DataContract” y “EnumMember”.
Os dejo además la URL del artículo que tomé de referencia, donde se amplía el uso de estas capacidades:
http://msdn.microsoft.com/es-es/library/aa347875.aspx
Y la solución en Visual Studio 2008 con los enumeradores incorporados:
Enumeradores en WCF
Saludos.
Miguel.
Permalink
06.25.08
Posted in Gestión de Recursos, Humor at 7:40 am by Miguel
Este artículo está dirigido a analistas, responsables de proyecto o demás profesionales que en su día a día realizan estimaciones y que además son amantes del fútbol.
Todos somos conscientes de la importancia de que la Selección Española de Fútbol haya roto el maleficio y se encuentre ya a disposición de jugar mañana jueves la semi-final de la Eurocopa, pero, por favor, no dejéis que la ola de alegría, júbilo, jolgorio, la sensación de que sois capaces de todo, deje que afecte a las estimaciones de esfuerzo que realizáis.
Para paliar los efectos secundarios del exceso de confianza, desde la máxima humildad, aconsejo aumentar entre un 5 y 10% las estimaciones que estéis adjudicando estos días (dependiendo de la complejidad técnica asociada). Confío plenamente que con este correctivo más de uno no se encuentre dentro de un par de semanas con el problema acumulado encima de la mesa (encima con lo malas que son estas fechas para pedirle a la gente que apriete el ritmo).
Saludos.
Miguel.
Permalink
06.24.08
Posted in Servicios Web, WCF at 7:41 am by Miguel
Y es que uno de los principales problemas que nos encontrábamos los desarrolladores de Servicios Web .NET de la versión 2.0, es cómo lanzar las excepciones tipificadas que definíamos en la capa de negocio para que pudieran ser capturadas desde la capa de presentación.
Para los que os hayáis encontrado ya con el problema, sabréis que toda excepción generada desde un Servicio Web .NET 2.0 llega a la capa de presentación como SoapException… por lo que es imposible tipificar en el cliente cuál ha sido exactamente el error generado por la capa de negocio. Hay algún truquillo por ahí pasando un XML en la SoapException y leyendo el XML desde el cliente, pero nunca me ha acabado de convencer.
Con la etiqueta FaultContract de WCF el problema ya está resuelto y vamos a ser capaces de definir excepciones en la capa de servicios que pueden ser capturadas desde el cliente. Os adjunto al post la solución de servicios polimórficos que vimos semanas atrás, añadiendo la casuística de la generación de excepciones y captura desde el cliente.
Fijaros entre otras cosas del código situado en Base.DAOException, que es la clase que utilizamos para el transporte de la excepción (atención, no hereda de Exception).
También en el interfaz que expone IMiServicio.cs, que es donde veréis que además del atributo “OperationContract” por cada uno de los métodos, también definimos “FaultContract”, asociado al tipo de excepción que va a ser capaz de lanzar dicho método.
[FaultContract(typeof(Base.DAOException))]
Fijaros en MarcaDAO.Update cómo lanzamos la excepción.
throw new FaultException<Base.DAOException>(new Base.DAOException(ex));
Pero, sobre todo, fijaros cómo se captura en el cliente Form1.cs
catch (FaultException<Servicio.DAOException> ex)
WCF Ejemplo FaultContract
Saludos
Miguel
Permalink
06.23.08
Posted in Servicios Web, WCF at 9:17 am by Miguel
Hola a todos.
Hace tiempo ya que tenía pendiente un artículo como este, donde se mostraba un ejemplo de evolución de un proyecto realizado con .NET Framework 2.0 y Servicios Web, a un proyecto hecho en WCF (siento el retraso, pero voy muy justo de tiempo ultimamente y casi no puedo avanzar artículos para el blog). La idea es que los profesionales que conozcan y estén acostumbrados a trabajar con Servicios Web 2.0, pierdan el miedo a WCF y vean que con cambios muy sutiles podemos reaprovechar el trabajo hecho y migrar a WCF.
Para ello os he preparado una solución que consta de dos proyectos, uno hecho con Servicios Web 2.0 y otro con WCF. El de WCF parte del de Servicios Web 2.0, lo ajusta para su uso en WCF y además aumenta la funcionalidad aprovechando el polimorfismo de WCF (tema que hablamos ya en un artículo anterior).
Entre las cosas que me gustaría que os fijarais es que en el proyecto de WCF se define un servicio “svc” y que dicho servicio está relacionado a un archivo “.cs” que implementa una interfaz. Esto se ha hecho con los servicios de “venta” y “mantenimiento”. Es obligatorio que cada servicio de WCF implemente una interfaz determinada. En la interfaz empiezan ya a verse atributos específicos de WCF como son “ServiceContract” y “OperationContract”. En cuanto a la capa de acceso a datos, en concreto en los DTO veréis aparecer etiquetas “DataContract”, “DataMember” y “KnowType”.
He añadido como complemento más ejemplos de usos de Polimorfismo en WCF. Como véis hay un servicio llamado “mantenimiento”, el cual llama a la factoría correspondiente seleccionando el DAO contra el que va a trabajar en tiempo de ejecución. Como sabéis esto no se puede hacer en Servicios Web 2.0.
Otro tema curioso es cómo se ha implementado el servicio de Venta en cada una de las aplicaciones, como veréis en la solución de WCF el método recibe un IDTO, mientras que como esto no es posible en Servicios Web 2.0, la firma del método cambia.
Ejemplo Transición Servicios Web 2.0 a WCF
Terminar diciendo que el ejemplo ha sido implementado usando como entorno de desarrollo Visual Studio 2008.
Saludos a todos.
Miguel.
Permalink
06.18.08
Posted in Noticias Actualidad at 10:49 pm by Miguel
Unos posts más atrás hablamos de http://www.navarradotnet.com, comunidad .NET de Navarra.
En el mismo post lanzaba al vuelo para cuándo, otras comunidades autónomas a las que me veo relacionado como son Aragón (donde trabajo) y Baleares (de donde soy) contarían con iniciativas similares de la de Navarra.
Pues bien, parece que para una de las preguntas ya tengo respuesta.
Os presento a Baleares on .NET
http://www.baleareson.net/
Saludos.
Miguel.
Permalink
06.12.08
Posted in BPM at 7:54 am by Miguel
Muy interesante.
http://is.tm.tue.nl/research/patterns/
¿Permite el motor de flujo que utilizáis la implementación de todos estos patrones? Podría ser una forma de medir la potencia que os aporta en comparación a otros motores de flujo del mercado.
Saludos.
Miguel.
Permalink
06.03.08
Posted in AgilePoint, BPM at 11:38 am by Miguel
Workflow Foundation, W4… son dos de los motores de flujo que hemos visto en otros posts de este mismo blog. Ahora le toca el turno a AgilePoint.
Entre sus principales características destaco:
1) 100% orientado a servicios, consumibles desde aplicaciones J2EE y .NET
2) Elaborado mediante .NET Framework 3.0
3) Integrado 100% en Microsoft Visio, permite diagramar los flujos directamente en Visio
4) Integrado 100% en Visual Studio, permite ampliar las capacidades base de AgilePoint
5) Es capaz de interactuar con Sharepoint, Biztalk, InfoPath.
Os dejo alguna captura de pantalla tanto de la integración con Visio como con Visual Studio
Saludos.
Miguel.
Permalink
