[Python-es] .NET Remoting en Python

[Hernan M Foffani]

>>>>> Q:
>>>>>  - Alguien conoce una librería que permita serializar objetos y mensajes
>>>>>    para obtener el formto binario del protocolo .NET Remoting ?
>>>>>
>>>>> Gracias por adelantado !
>>>>
>>>> Con IronPython tienes acceso a todas las librerías de .NET y mono no?
>>>>
>>>
>>> Sí, esto es completamente cierto y es una opción a valorar. De todas
>>> formas prefiero Python.NET porque brinda acceso a las clases del
>>> framework desde CPython y, por tanto hay más soporte y compatibilidad
>>> para las librerías (entre otras cosas ;o).
>>>
>>> Pero bueno, preferiría una librería que sea FOSS, hecha completamente
>>> en Python. Por eso pregunté ...
>>>
>>> Q:
>>>   - Alguien conoce una librería *HECHA CON PYTHON* que permita
>>>    serializar objetos y mensajes para obtener el formato binario del
>>>    protocolo .NET Remoting ?
>>
>> Si lo que es buscas una biblioteca hecha en Python, que solamente haga
>> uso de otras bibliotecas en Python que acceden a los system calls del
>> sistema operativo; no, no hay nada que yo sepa. Si bien el protocolo
>> de Remoting no es complejo, el problema está en serialización de
>> objetos. Dudo que alguien se haya tomado el trabajo de implementarlo
>> considerando que Remoting ha pasado de moda.
>>
>> Las alternativas que tienes son: IronPython, Python.NET (está
>> discontinuado) o una pasarela o proxy personalizado (que sólo abarque
>> la api de tu servicio) de Remoting a lo-que-sea (JSON, etc.)
>>
>> Nota: IronPython es Python y es FOSS. [Desde ya aviso que paso de
>> flamewars sobre este tema. Si no contesto es que estoy en desacuerdo
>> :-P]
>
>
> Antes que todo aclaro que hablo del .NET Remoting binario que tiene
> una implementación o binding en WCF (AFAIK Framework 3.5)

Pero a ver, ¿Es .NET Remoting o WCF? Son cosas distintas. El Remoting
viene desde la versión .NET 1.0. Ya en la 2.0 se recomendaba no usarlo
y lo nuevo se hacía vía WebServices. Y ahora lo guay es WCF.

> Q:
>  - ¿Porqué está pasado de moda?

Ni idea. Pregúntale a Microsoft.
La verdad es que tenía severas limitaciones.

> La alternativa de la pasarela no me sirve porque lo que pretendo es
> añadir soporte para .NET Remoting (HTTP binding) en una app web hecha
> en Python .
>
> La alternativa de IronPython + Python.NET no me sirve porque
> requeriría instalar Mono & Co. en GNU/Linux y hacer una buena cantidad
> de cambios en el Apache para hacer que todo eso corra . En definitiva
> , descartada (a no ser que no quede otra alternativa ...).

IronPython y Python.NET no pueden ir *sumados*. Disculpa si no me
expresé bien, pero son alternativas excluyentes.

Dado que tienes el Apache de por medio, piensa de nuevo en la
pasarela, por ejemplo, a JSON. Tu aplicación solo expone JSON, y *por
fuera* (separada del Apache), implementas una pasarela JSON<->WCF
escrita en IronPython o en C#.

>
> Faltó una alternativa «Do It Yourself» ;o) , pero si me pudiera evitar
> un poco de trabajo ...

No, no me he olvidado. Estaba implícita cuando te dije que el
protocolo de comunicación no es el problema mayor. Insisto, la
dificultad está en la serialización y deserialización de objetos .NET
a Python y vuelta. El tiempo que necesitarías para implementarlo es
enorme... Además, ¿Cómo vas a probar que tu interfaz funciona sin
programar en IronPython, C# o VisualBasic.NET?