Hace un tiempo publique en Netveloper un artículo sobre web services y object remoting. Puedes leer el artículo, pero también he decidido guardar una copia en este blog.

Conceptualmente Web Service y Remoting son lo mismo, objetos distribuidos. La diferencia principal es el protocolo.

En Remoting puedes usar protocolos no estándares. En Web Services usa SOAP, o RPC-XML, en genera estándares abiertos, sobre HTTP.

- Si quieres publicar a la web tus servicios, entonces debes usar Web Services, porque tus clientes pueden estar usando otro ambiente, como Java, PHP, etc, y lo que importa es la interoperabilidad.

- Si es para manejo interno, el remoting puede tener mejor performance si usas como otros protocolos, que usen TCP y manejen binarios, en vez de soap, de todas maneras remoting se puede hacer con soap pero es lo mismo que web services, si lo usas sobre IIS.

- Tu puedes tener remoting sin tener que instalarlos en el IIS. Eso puede tener ventajas también en el performance, pero tienes que preocuparte de blindarlo de todas las otras caracteristicas que te agrega IIS, como SSL, logging, seguridad, etc. En el fondo, es como que tuvieras que construir tu propio web server.
Por eso que se recomienda usar remoting en la intranet, donde normalmente la seguridad no es tan crítica porque se supone que todos los computadores son confiables (se supone).

- Probablemente, has visto mejor performance debido a la serialización. Los web services usan XMLSerializer, mientras que en remoting se usa SOAPFormatter o BinaryFormatter, que generan mensajes más comprimidos y se generan más rápido, además mandar un mensaje binario es más rápido que un XML, por ponerlo de algún modo. Además hay algunos detalles técnicos con respecto a la cantidad de conexiones que permite IIS sobre remoting, pero no creo que sea el caso.

¿Cómo decidir?

En Microsoft hay un artículo al respecto: ASP.NET Web Services or .NET Remoting: How to Choose

Otro artículo interesante está en Fuzzy Boundaries: Objects, Components, and Web Services.

En mi experiencia:

Si voy a interoperar con agentes externos, que no controlo, uso Web Services, porque es un estándar abierto.
Sólo uso object remoting en aplicaciones dentro de una intranet, porque muchas veces no puedes controlar los firewalls, routers, etc.
Sólo tiene sentido usar webservice u object remoting si los servicios van a ser usados entre máquinas distintas. Si no hay que usar objetos comunes y corrientes.
Object Remoting y Web services deben ser una interfaz a objetos de negocios internos, es decir, la lógica de negocios no debe estar en ellos, sino que en clases internas que se exponen usando estos mecanismos. Esto es conocido como el patrón Adapter o Wrapper, que sería más o menos como muestra la siguiente imagen:

Abusando de la notación UML, lo que la Figura muestra son algunas posibles configuraciones.

Tenemos:

Objeto de Negocio que implementa la lógica de negocios

Un WebService, que publica los servicios del objeto de negocios al mundo exterior.

Un Objeto Remoting que publica lo mismo para el mundo interior, usando object remoting.

Tenemos un cliente interno que podría usar web services o remoting.

Un cliente interno que usa directamente el objeto de negocios.

En este patrón usamos el web service y el remoting como un Wrapper, para publicar la funcionalidad, que la realiza el objeto de negocios, eso nos da flexibilidad, y re utilización de lógica.

Publicado por ediaz a las 10:14 PM | Enlace permanente | Comentarios (0) | TrackBacks (0)

Las reglas de la programación orientada al objeto (OOP) dicen que no se puede llamar a un método privado de una clase.

De modo que si se tiene la siguiente clase:

class MiClase
{
   private void MetodoPrivado()
   {
      System.Console.WriteLine("método privado invocado");
   }
}

No es posible llamar al método MetodoPrivado desde otra clase, incluso desde una clase derivada.

Rompiendo las reglas

Pero en C# usando Reflection es posible saltar esta restricción, y llamar un método privado.

El siguiente código muestra cómo 

using System;

using System.Reflection;

public class PrivateCaller
{

   static void Main()
   {

     PrivateClass a = new PrivateClass();

     BindingFlags eFlags = BindingFlags.Instance

                 | BindingFlags.Public

                 | BindingFlags.NonPublic;

     MethodInfo m;

     try
     {

        m = t.GetMethod("PrivateMethod", eFlags);

        if (m != null)
        {

          m.Invoke(objInstance, aobjParams);

        }

    }

    catch
    {
       throw;
    }
  }
}

Por supuesto esto se puede evitar aplicando el atributo ReflectionPermission.

¿Para qué podría usarse esto?

Un uso interesante es cuando quieres hacer testing de clases, usando NUnit, por ejemplo, en ese caso puedes usar esto para probar métodos privados de una clase.

Otro uso es para invocar métodos de una clase a la cual no tienes acceso para modificarla. 

Publicado por ediaz a las 07:09 PM | Enlace permanente | Comentarios (0) | TrackBacks (0)

Aqui hay 7 consejos para el uso de excepciones en C#, pero creo que son también útiles para Java.

1) No utilice las excepciones para controlar el flujo de la aplicación.
2) Usar código de validación para evitar excepciones innecesarias.
3) Usar el bloque finally para asegurar la liberación de los recursos.
4) No atrape las excepciones que no va a manejar. .
5) Tenga en cuenta que relanzar excepciones (rethrowing) es costoso. Casi tan costoso como la excepción que se produjo.
6) Preservar toda la información de diagnóstico posible en los manejadores de excepciones. Esto es util para efectos de depurar.
7) Utilizar el Monitor de Performance para monitorear excepciones del CLR.

Gracias a Juan Daria Tempesta (Instructor DCE) por inspirar este artículo

Publicado por ediaz a las 06:31 PM | Enlace permanente | Comentarios (0) | TrackBacks (0)