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