Un viaje sobre lenguajes, APIs y otras cosas raras en el mundo del desarrollo de sistemas.

WCF y el nuevo martirio


Una vez realizado lo anterior empecé a luchar con lo que Microsoft llama "Partially Trusted Environment" que es el hecho de que el Applet… chales, perdón, el XBAP -por que ya tampoco le podría llamar control de ActiveX que sería su ancestro dentro de la tecnología MS, y que por cierto es posterior al Applet y fue muy criticado por sus deficiencias en la seguridad-… decia  que el Applet funciona en un SandBox, es decir en una serie de restricciones que hacen que muchas cosas no puedan realizarse, de hecho y como lo ha reconocido MS en algunos de los threads que he tenido en los foros MSDN, incluso hay código que "por falta de recursos no se han auditado y por lo tanto son marcados como inseguros", por esto es que un RichTextBox, un muy buen control dentro del WPF no puede cargar (el dia de hoy) un RTF desde un sitio remoto.
El sandBox de un XBAP solamente permite comunicarse al mismo sitio de origen, a diferencia de un Applet el sitio de origen no implica solamente la dirección IP, sino también el protocolo (http/https) y, en su caso el puerto de comunicación. Es por eso que solamente podría cargarse como datos desde dicho sitio aquellos obtenidos via WebServices o bien, via un ASP si se quiere desplegar una página HTML.
La idea de usar WebServices me gustó mucho, pero el infierno de la configuración y de la escasa documentación me perseguían sin que lo buscara… ¡Cómo extrañe el poder hacer una comunicación via un socket de TCPIP como lo llegué a hacer hace muchos años para un Applet que permitía a los usuarios seguir a tiempo real las competencias de carreras de autos, en esa solución nos counicabamos al servidor web mediante un protocolo propietario que nos permitía una mayor velocidad
Regresando a mi Applet (XBAP) resulta que la caja de seguridad solamente nos permite contactarnos, por lo tanto, hacia "el sitio de origen" y con ello la forma de obtener los datos mediante WebServices resulta ser "Natural" mediante el Windows Comunication Framework (WCF). Este framework permite de una manera muy sencilla generar los webservices, basta generar un proyecto para tal fin y seguir las siguientes reglas:
  1. Se genera una interfaz donde se establecen los servicios a publicar y se les pone la anotación [OperationContract], con lo que el compilador hace lo correspondiente para generar el wsdl y demás partes involucradas.
  2. Se generan los objetos de transferencoa (TO) y se establecen las clases como [DataContract] y a cada propiedad se le define como [DataMember], los DataMembers deben tener tanto getters como setters para poder ser válidos. p.e. public int  MiPropiedad{get;set;}
  3. Se establece la configuración adecuada (aquí es donde empiezan los dolores de cabeza).
  4. Se genera una relación en las referencias para la clase cliente (o se siguen los pasos que daremos a conocer).

El archivo de configuración tiene varias limitantes, pero muy pocas de ellas ns sacarán de problemas si no sabemos que está pasando. Si estamos generando un prototipo, incluso, es posible que no nos demos cuenta que nuestro producto final  pueda fracasar.
Por omisión en WPF varios de las limitantes para los objetos de transferencia son cercanos a los 64KB, lo cual para servicios básicos de pocos datos es muy adecuado, sin embargo si estamos esperando que nos envíen resultados de más de 200 registros con varios datos…. podemos experimentar problemas de los cuales no nos daremos cuenta hasta que utilicemos la muy poco documentada propiedad:
<listeners>
          <add name="tracelistener"
               type="System.Diagnostics.XmlWriterTraceListener"
               initializeData="C:\logWCF.svclog"/>
        </listeners> 
Con lo cual el WebService creará su log de errores en C:\logWCF.svclog, sin esto cualquier error referente al WS perse será invisible para nosotros y no sabremos que moverle a nuestro archivo de configuración.
Generalmente podremos recurrir a mover los siguientes parámetros (esto se hace en el xml del cliente):
<behavior name="wsHttpBindingBehavior">
          <dataContractSerializer maxItemsInObjectGraph="653566666"/>
        </behavior>
Donde establecemos el tamaño máximo que debe tener nuestro objeto más grande para transferirlo (en Bytes), en este caso estamos dando la "minucia de 650 MB aprox, lo cual es una exageración, por supuesto.
Otros parámetros que se pueden utilizar para mover son:
<binding name="WSHttpBinding_IFachadaBusquedaTradicional"
                 closeTimeout="00:01:00"
                 openTimeout="00:02:00"
                 receiveTimeout="00:10:00"
                 sendTimeout="00:10:00"
                 bypassProxyOnLocal="true"
                 hostNameComparisonMode="StrongWildcard"
                 maxBufferPoolSize="0"
                 maxReceivedMessageSize="655366666" transferMode="Streamed"
                 messageEncoding="Text" textEncoding="UTF-8"
                 useDefaultWebProxy="true"
                 allowCookies="true">
          <readerQuotas  maxDepth="1665632"
                        maxStringContentLength="16666819"
                        maxArrayLength="6661638"
                        maxBytesPerRead="4096"
                        maxNameTableCharCount="661638" />
Notese la codificación  del texto, en numero maximo para el mensaje recibido y el string mas largo.
Cabe mencionar que en un ambiente Parcialmente Confiable (Partially Trusted) NO podemos utilizar el protocolo de WebServices WsHttpBinding, de hecho el único aprobado por MS para dicho fin es el BasicHttpBinding, con lo cual NO podremos hacer uso de MOM y otras ventajas de los WS…. este es otro dato difícil de encontrar y, más aún, de creer.
Para generar mi parte de cliente yo utilizo desde línea de comandos la utilería svcutil, la cual me genera las clases TO del lado del cliente y me definen la clase de mi fachada para comunicarme con el WS, generalmente uso el comando: svcutil.exe http://localhost:8731/Design_Time_Addresses/WcfForIusWeb/Fachada/?wsdl
Eso me genera el archivo .cs y el .config, que lo modifico según lo que ya les expliqué.
En el próximo post veremos más a fondo la creación del Cliente y los problemas de como probarlo… por que Visual Studio no te lleva a donde quieres llegar hoy.
Saludos hasta la próxima

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: