Comment on Naming Conventions for Communication Channels

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Comment on Naming Conventions for Communication Channels

grampajohn
Administrator
Since the github wikis do not have "discussion" pages, I would like to suggest that we use this channel for such discussion, and that the final result of any such discussion should appear back on the wiki. In the meantime, we can post links from the wiki pages to Nabble pages to keep them in sync. Alternative proposals are welcome, of course.

This discussion is regarding the wiki page https://github.com/powertac/server/wiki/Naming-conventions-for-communication-channels.

I am a big fan of naming conventions, and so I applaud this effort. I have a couple of thoughts on this particular convention:

- Naming a channel for source and destination could create unnecessary coupling, and therefore future confusion, it seems to me. Would it not be better to name a channel for the kind of information it carries, and let component writers decide whether their components need to access that information? For example, there could be a "tariff update" channel, containing new (public) tariffs, tariff expirations and retractions, etc. Presumably the source of this channel would be the Brokers collectively, but the destination would be any component that was interested in seeing tariff updates.

- Including the type of object in the channel name implies that a channel can carry only one type of message. Is this intentional? Does it make sense?

- Insisting that every message type include the string "Command" as part of its name introduces unnecessary redundancy, IMHO. If they all have it, then the result is indistinguishable from none of them having it. It ceases to have any significance. Or are you trying to distinguish these types from non-message types? The purpose is not clear. Would it not be enough to use a name composed of a base type (Tariff) and an action word (Publish)?

- This convention assumes that everything we communicate is a "command," but if you read the material on enterprise architecture integration, the messages are called "events." The term "command" is likely to imply that the objects are intended to play a particular role in the GOF Command Pattern. I'm not sure that's the case for most of these types.

Just a suggestion...

John
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Comment on Naming Conventions for Communication Channels

ddauer
- Naming a channel for source and destination could create unnecessary coupling, and therefore future confusion, it seems to me. Would it not be better to name a channel for the kind of information it carries, and let component writers decide whether their components need to access that information? For example, there could be a "tariff update" channel, containing new (public) tariffs, tariff expirations and retractions, etc. Presumably the source of this channel would be the Brokers collectively, but the destination would be any component that was interested in seeing tariff updates.


A (default) channel is a connection between two entities, the message producer and the message consumer. Therefore naming should be as specific as possible, as there will be a lot of channels. Using general names such as "tariff update" channel introduces room for error as it is not clear who is supposed to publish or consume the message. There can be of course multiple consumers within a "publish-subscribe-channel" pattern, where the naming would be something like "<source><command>Channel" vs. "<source><destination><command>Channel".
 
- Including the type of object in the channel name implies that a channel can carry only one type of message. Is this intentional? Does it make sense?

Yes, this is intentional. Also, a channel in general can carry any type of message.
 

- Insisting that every message type include the string "Command" as part of its name introduces unnecessary redundancy, IMHO. If they all have it, then the result is indistinguishable from none of them having it. It ceases to have any significance. Or are you trying to distinguish these types from non-message types? The purpose is not clear. Would it not be enough to use a name composed of a base type (Tariff) and an action word (Publish)?

I think this is a good idea. Commands are located in the .commands package, so that should be pretty clear. After all, we're not adding "Interface" to interfaces.
 

- This convention assumes that everything we communicate is a "command," but if you read the material on enterprise architecture integration, the messages are called "events." The term "command" is likely to imply that the objects are intended to play a particular role in the GOF Command Pattern. I'm not sure that's the case for most of these types.

There are event messages as well as document messages (1) and I guess we're using both. I can see that "command" does not really fit the GoF Command Pattern, but I don't have any other suggestions right now.

- David
 

Loading...