Direct connection of interface-driven services from a rich C# client

Roberto Schneiders · 2013-01-11 13:08:12

We currently have clients Delphi and C # consuming a DataSnap server. My idea is to create a new one using the mORMot framework.

On the roadmap are these two items:
- Direct connection of interface-driven services from a rich AJAX client built with Smart Mobile Studio;
- Direct connection of interface-driven services from a rich C# client, with a code generation tool;

In DataSnap we have the proxy classes and MobileConnector's helping with C#. But the way we work just with interfaces in mORMot is fantastic, much better, but only for Delphi clients. I imagine that these items of roadmap reference it. Could spend more information on how this would work?

The way of working with server classes (A service for example) in C# would be similar to Delphi? Or the communication with the server must be implemented manually, as it is today.

You plan to work on these items soon or they will take time to be implemented?

Last edited by Roberto Schneiders (2013-01-11 13:08:43)

ab · 2013-01-11 13:59:15

Communication is pretty simple.
You have a HTTP REST query, sending the input parameters of the method as JSON array, and retrieving the result as a JSON object, with all outgoing parameters sent as a JSON array.
Framework documentation gives details about the layout.
See also http://blog.synopse.info/post/2012/03/0 … on-details

What you need to add to standard RESTful WCF client.
See http://shop.oreilly.com/product/9780596529260.do

Only particularity of mORMot is the session handling.
If you want to create some per-session instance, or use mORMot security attributes for your services, you need authentication.
It need some kind of URI signature, not difficult and well defined - see , but for which there is no C# code by now (only AJAX code).
http://blog.synopse.info/post/2011/05/2 … entication

I plan to add some automated C# clients code generation from server.
My proposal is to have the possibility to expose directly the method C# code from a RESTful request, if the server is run in debug mode (inside the Delphi IDE). A SmartObject pascal code may also be published directly.
Something like:
- http://localhost:888/root/ServicesSignatures/MyService/Method/cs for a given method;
- http://localhost:888/root/ServicesSignatures/MyService/cs for a given service;
- http://localhost:888/root/ServicesSignatures/cs for all services.
Here, /cs at the end will ask for a C# source code, but we may put /sms for Smart Mobile Studio.

And just http://localhost:888/root/ServicesSignatures for a simple HTML page allowing to browse all available services, and get the .cs / .pas wrappers in one click.

Of course, including authentication code, if needed.

Does it make sense to you?

Roberto Schneiders · 2013-01-11 16:02:01

Yes, this makes perfect sense to me.

I still know little bit of the framework, so I apologize if I'm doing stupid questions.

I still have doubts about this C# code that will be generated.
Basically these codes are the public interfaces? Or in the case of C# would be only DTO's classes?

In delphi I do not need to worry about REST requests or JSON parsers. In C# I have to do this manually?

Is there the possibility of having the service factory in C#? So I could use it in C# in the same way that I use in Delphi. Example: fClient.Services.Info (typeinfo (ICalculator).) Get (I)

Obviously there had to be a part of the framework implemented in C#. But that would be possible? Do you think that is feasible?

ab · 2013-01-11 17:11:24

What I had in mind is to have a C# class wrapper created on purpose, with all marshalling made in C# code.
Using WCF RESTful URIs and JSON marshalling.

I'm quite sure that we may be able to create the wrapper from the C# interface RTTI, but it would be a lot of work.
More work than creating a C# class client, which was what I had in mind.
I'm less fluent in C# internals and RTTI than in Delphi's... do you have any idea?

Any help is welcome, in C# implementation.

Roberto Schneiders · 2013-01-11 17:32:33

I also do not know much C#, but have three C# developers working here. Maybe we can develop it.

I'll talk to those developers to see if they have any idea how to do this.

Roberto Schneiders · 2013-01-11 19:46:49

Can I use the ServiceModel Metadata Utility Tool (http://msdn.microsoft.com/en-us/library/aa347733.aspx) on a mORMot server ?

I saw your response on this link but i not sure
http://stackoverflow.com/questions/5650 … and-delphi

ab · 2013-01-11 22:14:16

Is not this tool only to work with WSDL/SOAP only?

mORMot uses a RESTful / JSON scheme.

Roberto Schneiders · 2013-01-14 10:45:27

I do not know.

As I understand it is a tool primarily used by WCF clients (which in theory is SOA. I am no expert on this, forgive me if I'm wrong. Maybe wikipedia is misleading me http://en.wikipedia.org/wiki/Windows_Co … Foundation) .
http://msdn.microsoft.com/en-us/library/aa751905.aspx

Apparently I misunderstood your answer on StackOverflow.
In your answer you put "It is ready to be Consumed by AJAX clients or WCF (after the latest custom marshaling of the interfaces)". So I thought that maybe there was some implementation for WCF tools.
In that case, what do you mean by "after custom marshaling of the interfaces"? Translate the object pascal code to C #?

Thank you.

Last edited by Roberto Schneiders (2013-01-14 12:51:55)

ab · 2013-01-14 16:35:37

"after custom marshaling of the interfaces" refers to C# methods marshalling using WCF RESTful process.

WCF is much more than SOAP, but most of the integrated tools are SOAP-based, or WCF-native.
For RESTful tools, you need to map the URIs by hand, in your C# method definitions, using attributes.

By "it is ready", I meant that it can be consumed by C# clients, if you marshall the JSON content as requested.
But code is to be written by hand, until we provide a wizard or a http endpoint generating C# wrappers - as I proposed above.

mORMot Open Source

#1 2013-01-11 13:08:12

Direct connection of interface-driven services from a rich C# client

#2 2013-01-11 13:59:15

Re: Direct connection of interface-driven services from a rich C# client

#3 2013-01-11 16:02:01

Re: Direct connection of interface-driven services from a rich C# client

#4 2013-01-11 17:11:24

Re: Direct connection of interface-driven services from a rich C# client

#5 2013-01-11 17:32:33

Re: Direct connection of interface-driven services from a rich C# client

#6 2013-01-11 19:46:49

Re: Direct connection of interface-driven services from a rich C# client

#7 2013-01-11 22:14:16

Re: Direct connection of interface-driven services from a rich C# client

#8 2013-01-14 10:45:27

Re: Direct connection of interface-driven services from a rich C# client

#9 2013-01-14 16:35:37

Re: Direct connection of interface-driven services from a rich C# client

Board footer