Software Design/Modelling for WAMP

#1

Traditionally in an RPC framework we would have the notion of a client and a service. As a result we would typically put all of the caller functionality into an object/class called client and all of the callee functionality into an object/class called service. Anyone that wants to interact with the service can instantiate a client, connect to the service, and issue calls.

With WAMP components we don’t really have the traditional notion of clients and services as it is more like a peer-to-peer architecture. So we write component classes to encapsulate the behaviour of that component.

  • So what are the best practices for software design in WAMP?
  • What are the common patterns that I can model in order to build up a framework that is intuitive and promotes code reuse?

For example, say I have the following contrived example:

Each component is going to need access to the configuration. But the configuration component has all of the logic of things like publishing and such baked into it.

  • So what is the best way to encapsulate the client functionality of the configuration so it can be used by everyone?
  • Would I write a configuration::client, and a configuration::component?

The other thing I am thinking about is subscriptions. It would seem convenient to put all of the subscription code together into a class/object as well. So this leaves us with something like:

configuration::client

configuration::component

configuration::subscriptions

In the case of the scheduler component then, it would create a session with the router and then create an instance of the configuration::client, configuration::component, and configuration::subscriptions objects and pass in a reference to the session?

0 Likes