[en] RPC abstraction layer

Topics: Announcements
Coordinator
Aug 14, 2011 at 9:31 PM
Edited Nov 24, 2011 at 10:05 AM

Hi, Rainbird!

Zyan Framework currently acts as a higher-level facade to .NET Remoting.
The obvious step further would be an abstraction layer which allows plugging in other RPC frameworks.

So, instead of

Client → ZyanProxy → [Remoting] → ZyanDispatcher → Server Component

we'd have

Client → ZyanProxy → [RPC Layer] → ZyanDispatcher → Server Component

where RPC Layer is one of the following:

Server protocol setup class is responsible for creating and publishing remote ZyanDispatcher.
Client protocol setup is used to establish connection with ZyanDispatcher and create a local proxy implementing IZyanDispatcher interface.

Remoting and WCF backends should be built-in.
Other RPC framework backends could be implemented as a separate plugins.

Do you think it's possible?

Coordinator
Aug 15, 2011 at 5:39 AM

Hi, yallie!

Almost everything is possible, but at what time and effort?
Even with a RPC abstraction layer Zyan will not be compatible to these other RPC frameworks because it completly encapsulates them.

So - as faar as I see - this will be the remaining benefits:

  • Possible use of Zyan on environments where .NET Remoting isn´t availabe
  • Freedom to use special RPC frameworks

But what minimum set of features can we expect that every RPC framework has?

Implementing simple RPC calls with WCF would be easy. But delegates and events will be difficult. Zyan currently makes rich use of .NET Remoting features for delegate and event support.

It would mean much work, but I think it is possible.
Before we start to deconstruct the current Zyan architecture and plug some abstraction layer in, we should make some tests to get an overview about the needed effort.

Coordinator
Aug 15, 2011 at 5:17 PM
Edited Aug 15, 2011 at 5:21 PM

>Almost everything is possible...

Haha, I fully agree :)

>Even with a RPC abstraction layer Zyan will not be compatible
>to these other RPC frameworks because it completly encapsulates them.

No, compatibility is not the goal.

The goal is to provide Zyan services (authentication, event handling, LINQ support,
MEF integration) on top of other RPC frameworks meeting certain simple requirements.

>But what minimum set of features can we expect that every RPC framework has?

If Zyan had the following features:

  • ZyanDispatcher runs on both sides of the connection: #1090
  • Zyan can pass references to remote components, similarly to ObjRefs in Remoting: #766

then the requirements are minimal.

I.e., we could use any RPC framework that allows calling IZyanDispatcher methods.
Plain old web-services, perhaps.

>Zyan currently makes rich use of .NET Remoting features for delegate and event support.

You are probably talking about DelegateInterceptor?

DelegateInterceptor is an MBR object, which is handled by Remoting infrastructure automatically.
We can create DelegateInterceptor and pass it over the remoting channel, and the rest is done for us.
Very convenient.

But if we enable Zyan to handle remote component references and register new DelegateInterceptor
instances on-the-fly (for every event handler), then we probably could mimic this behavior using any
simple RPC layer, just like custom serialization handlers process non-serializable classes.

>Before we start to deconstruct the current Zyan architecture and plug some abstraction
>layer in, we should make some tests to get an overview about the needed effort.

Yes, of course.

I don't think we should invest much time in this feature in the nearby future.
I'd suggest to schedule it for, say, Zyan 4.0 :)

Instead of Silverlight port.

Coordinator
Aug 15, 2011 at 8:47 PM

OK. The ability to use Zyan on Silverlight or Compact Framework Clients justifies the effort.

Let´s see the RPC abstraction layer as long term goal.