+ + Non-prerelease WampSharp version +
+ + + +Yesterday I released the first non-prerelease version of WampSharp. This was requested and discussed by the community in this issue.
+I thought to take this opportunity to write a bit about this open source project, and my journey in the WAMP world.
+I began working on WampSharp in April 2013. I looked for a WebSocket subprotocol which supports both RPC and PubSub, and came across this answer on StackOverflow. The first version was released around July 2013 and contained WAMP v1 support for both server and client sides. During its first year, the project did not receive almost any attention from the community.
+Around December 2013, work on WAMP v2 spec began. Around late September 2014, the first WampSharp version supporting WAMP v2 was released. Since then, I’ve released every year at least one major WampSharp version, and several hotfix versions, summing up to 53 versions. Usually the annual major version tries to catch up with Crossbar.io.
+Community
Nowadays, WampSharp has dozens of users, spread all over the world. A lot of WampSharp’s development is due to the community. This involves some features (mainly authentication features), bug reporting and bug fixes. There were several times where community members helped me figure out how to reproduce a previously reported bug.
+Contribution to other open source projects
WampSharp’s presence made me and others contribute to other non-WAMP related projects, as some of the issues filed for WampSharp turned out to be issues of other libraries. These include feature requests and issue filing for WebSockets libraries, and sometimes even pull requests to resolve these! Beside these, I submitted various pull requests for LibLog and also filed issues for the .NET MessagePack implementation, and even for Mono and IIS Express! These were all found via WampSharp related scenarios.
+I also tried to contribute to the WAMP ecosystem in various ways. These include providing a C# template to Crossbar.io, providing type declarations for AutobahnJS (the most popular JavaScript implementation of WAMP), providing WAMP messages parsing code for a Firefox developer extension. I also created a project called meta-wamp which provides WAMP messages declaration files, from which one can generate a WAMP related library.
+Bringing WampSharp features to other languages
In my opinion, the reflection based roles are among the nicest features WampSharp has to offer. I tried mimicking this in other languages. One attempt was the TypedAutobahn project, which, unfortunately, was never completed. A couple months ago, I submitted an initial reflection based features pull request to autobahn-java, which was merged. Hopefully, this feature will be useful for WAMP Java developers.
+Future
It seems that WAMPv2 has kind of staled, and that the most critical period of its development was around 2014-2015. Hopefully, .NET Core has staled, and I won’t have to make any more crazy changes in order to keep supporting this platform. I do plan to continue maintaining WampSharp, which includes answering questions and handling issues on GitHub. I hope I’ll be able to release at least one major version per year.
+ +
+ CodeSharp
+Stronger Better Faster Sharper
++ Introducing TypedAutobahn +
+ + + +In this post I want to introduce a project I’ve been working on lately.
+The project is named TypedAutobahn. It is a project that aims to bring strongly typed programming style for WAMP in TypeScript.
+I don’t intend to write here much about WAMP. WAMP (not to be confused with Windows Apache MySQL PHP) is a protocol that provides patterns of Remote Procedure Call and Publish/Subscribe. WAMP usually runs over WebSocket + JSON, but other options exist as well (such as RawSocket and MsgPack). WAMP has various implementations in various languages.
+I have written a C# implementation for WAMP, which provides both client and router support, it is called WampSharp.
+WampSharp reflection based-api
One of the features WampSharp provides, is some reflection-based api for the WAMP roles. The api reminds a bit WCF’s ServiceContracts. For instance, in order in to call a procedure, we define the following contract:
+1 | public interface ICalculatorProxy |
and then request a proxy for it and call the procedure:1
2
3
4
5
6ICalculatorProxy proxy =
channel.RealmProxy.Services.GetCalleeProxy<ICalculatorProxy>();
int five = await proxy.Add2Async(2, 3);
Console.WriteLine($"Result: {five}");
(This code isn’t complete, I am omitting for clarity the code that setups the WampChannel object denoted as the channel variable).
+Similarly, registering a procedure is done in the following way:
+Define a contract and implement it:
+1 | public interface ICalculator |
then register an instance of it:
+1 | ICalculator instance = new Calculator(); |
Similar features are available also for publisher and subscriber roles. (see also documentation)
+AutobahnJS
AutobahnJS is a WAMP client library written in JavaScript. It runs both on Node.js and browsers. It has been written and maintained by the Crossbar.io team which consists of the people who have created WAMP. AutobahnJS is very popular among WAMP implementations.
+Lets review how the preceding samples look using AutobahnJS:
+Procedure call:1
2
3
4
5session.call('com.arguments.add2', [2, 3]).then(
function (res) {
console.log("Result:", res);
}
);
Procedure registration:1
2
3
4
5function add2(args) {
return args[0] + args[1];
}
session.register('com.arguments.add2', add2);
As before, similar api exists for Publish/Subscribe roles.
+The problem
Although AutobahnJS api is very simple, it might be challenging to consume services which have a large domain.
+Suppose you have written a service that takes a use of lot of contracts in C#. Suppose that now you want to consume that service from JavaScript. It might be challenging to be familiar with all service aspects from JavaScript, since JavaScript is a dynamic-typed language, i.e. has no “hard-coded types”, and therefore you don’t have intellisense.
+So you might consider using TypeScript, which allows you to define types and interfaces and enjoy advantages of static-typed languages (such as intellisense) for JavaScript programming.
+Luckily, there exist type declarations for AutobahnJS that give intellisense for AutobahnJS (These declarations were mostly written by me). These give intellisense for AutobahnJS, but don’t help you consume your services.
+It would be nice if we could just “export” our domain written C# to TypeScript, so we could immediately start consuming our services from TypeScript. This is what TypedAutobahn attempts to achieve.
+TypedAutobahn
TypedAutobahn currently consists of two parts: a (relatively small) TypeScript library which consists of types and methods that are been used by generated code, and a code generator written in C# which generates code based on given contracts.
+For instance, suppose we have the following contract in C#:1
2
3
4
5
6
7
8
9
10
11
12
13
14public interface IArgumentsService
{
[]
void Ping();
[]
int Add2(int a, int b);
[]
string Stars(string nick = "somebody", int stars = 0);
[]
string[] Orders(string product, int limit = 5);
}
Running the code generator for this contract yields some code which contains the following contracts:
+1 | interface IArgumentsService { |
A class named IArgumentsServiceProvider which allows us to consume the services is also generated.
+Consuming caller services with TypedAutobahn has the following form:1
2
3
4
5
6
7
8
9
10
11
12
13
14let serviceProvider = new IArgumentsServiceProvider(session);
let proxy = serviceProvider.getCalleeProxy();
proxy.ping().then(() => console.log("Pinged!"));
proxy.add2(2, 3).then(res => console.log("Add2:", res));
proxy.stars().then(res => console.log("Starred 1:", res));
proxy.stars("Homer").then(res => console.log("Starred 2:", res));
proxy.stars(null, 5).then(res => console.log("Starred 3:", res));
proxy.stars("Homer", 5).then(res => console.log("Starred 4:", res));
proxy.orders("coffee").then(res => "Orders 1:", res);
proxy.orders("coffee", 10).then(res => "Orders 2:", res);
The nice thing is that we have intellisense - the editor gives us auto-completion for proxy methods and for their return values. Also, we don’t need to be worried about the WAMP procedure uris - these are specified in the generated code. The sample here is rather simple, but the generator also generates contracts for composite types your methods receive/return.
+This is even more incredible than it looks: if we’re targeting Node.js, we can use async/await:1
2var five = await proxy.add2(2, 3);
console.log("Add2: ", five);
Similarly, we can register WAMP procedures using the IArgumentsServiceProvider. Consider this implementation for instance:
+1 | class ArgumentsServiceCallee implements IArgumentsService { |
We simply register it using
+1 | let serviceProvider = new IArgumentsServiceProvider(session); |
This registers all methods of the IArgumentsService contract, using the procedure uris specified in the C# code. Note that the methods no longer receive an arguments array that needs to be manually unpacked, but TypedAutobahn unpacks it automatically: first it searches for positional arguments, and if those aren’t present, it searches for keyword arguments having the names of the method arguments. If none of these are found, the default value specified is used.
+A similar mechanism which mimics WampSharp’s reflection-based subscriber exists for subscribers.
+Current status
I made the TypedAutobahn repository public not long ago. You can find it on GitHub.
There are a few things that are missing: regarding features, there is currently no support for publisher role.
Regarding other stuff: some work on deployment needs to be done: the project currently targets Node (since it uses export/import syntax). A build that creates a version that is browser-friendly should be set. Also, a package for npm/bower/NuGet should be created and published automatically on builds.
I should probably open GitHub issues regarding these. Any help on these or on anything else would be appreciated!
Future
TypedAutobahn is cool, but it is very limiting, since it requires you to have C# code representing your WAMP service contracts. It would be awesome if we could be able to generate code for WAMP service contracts, regardless the language they are written in. This should be possible in the future, since WAMP has reflection on its roadmap (See also these links: #1 #2 #3 #4).
This feature should allow to generate code representing a WAMP service contract of a living contract. Once it would be present, the current code generator could be replaced with a new code generator (probably written in JavaScript/TypeScript) which allows to generate code to many target languages regardless of the language the original service was written in.
+ CodeSharp
+Stronger Better Faster Sharper
+