[Python-es] .NET Remoting en Python

Olemis Lang (Simelix) olemis+py en gmail.com
Jue Mayo 27 15:12:50 CEST 2010


2010/5/27 Hernan M Foffani <hfoffani en gmail.com>:
>>>>>> 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?
>>>>>
>>>>
[...]
>>>>
>>>> Pero bueno, preferiría una librería que sea FOSS, hecha completamente
>>>> en Python. Por eso pregunté ...
>>>>
[...]
>>>
>>> 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.

No, para nada. WCF es una API para RPC, multi-protocolo, que tiene un
binding para MS-NRBF sobre TCP y HTTP , otro para SOAP con diferentes
transportes, otro para los WS-* , ... , más los que se le puedan
ocurrir a alguien que haga sus propios bindings o los que resulten de
ensamblar binding elements existentes o nuevos. Mientras que .NET
Remoting Binary format (código del estándar MS-NRBF ;o) es un
protocolo binario para serializar mensajes RPC .

Para que quede más claro : NRBF es un protocolo (o tecnología de
serialización) para RPC, mientras que WCF es una API . Como me diría
alguien alguna vez «oranges and apples, Olemis» ;o)

> 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.

El NRBF es más o menos lo mismo pero binario y «más eficiente» (de
hecho el MS-NRTP a.k.a. .NET Remoting Core Protocol Specification
tiene un binding para SOAP y otro binario ;o)

> Y ahora lo guay es WCF.
>

¿Por qué lo dice MS?
;o)

Bien, poniendo a funcionar mis neuronas creo que logro darme cuenta de
que me venden esencialmente lo mismo con una nueva envoltura
(envoltura que resulta ser lo que es más guay ;o). Lo que sí es nuevo
es los bindings ws* .

>> Q:
>>  - ¿Porqué está pasado de moda?
>
> Ni idea. Pregúntale a Microsoft.

Bueno MS no fue quién lo dijo en mensajes anteriores ;o) . ¿Al menos
recuerda Ud donde es que MS lo dijo?

> La verdad es que tenía severas limitaciones.
>

Bueno, comparado con otras cosas, puede ser . Pero e.g. para publicar
servicios en una intranet y aprovechar el ancho de banda
(desperdiciado miserablemente por super-SOAP) ...

DISCLAIMER: No es que me guste mucho la idea de usar .NET Remoting,
pero parece que a otros sí ...
;o)

>> 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.
>

El que se expresó mal fue yo . Donde dije *digo* (i.e. IronPython +
Python.NET) digo *Diego* (i.e. IronPython | Python.NET)

:-S

> 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#.
>

La aplicación web de la que hablo ya tiene soporte para (XML|JSON)RPC
, pero se desea añadirle soporte para MS-NRTP + MS-NRBF .

>>
>> 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?

De la misma forma que se puede utilizar HessianPy , PyAMF et al (i.e.
todos protocolos para RPC diseñados para lenguajes que no tienen nada
que ver con Py ;o) sin necesitar Java, ni ActionScript, ni ... ;o)

El papel de C# et al en este caso solo lo veo relacionado con algún
tipo de suite de pruebas + CI para verificar interoperabilidad con
esas plataformas .

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Control de usuarios personalizado con Apache y mod_authnz_external -
http://feedproxy.google.com/~r/simelo-es/~3/cBNqfg_xMaw/control-de-usuarios-personalizado-con.html



Más información sobre la lista de distribución Python-es