Home/ Questions/Q 326461
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T09:18:41+00:00

I want to separate modules of my program to communicate with each other. They

  • 0

I want to separate modules of my program to communicate with each other. They could be on the same computer, but possibly on different ones.

I was considering 2 methods:

  1. create a class with all details. Send it of to the communication layer. This one serializes it, sends it, the other side deserializes it back to the class and than handles it further.
  2. Create a hashtable (key/value thing). Put all data in it. Send it of to the communicationlayer etc etc

So it boils down to hashtable vs class.

If I think ‘loosely coupled’, I favor hashtable. It’s easy to have one module updated, include new extra params in the hastable, without updating the other side.

Then again with a class I get compile-time type checking, instead of runtime.

Has anyone tackled this previously and has suggestions about this?

Thanks!

edit:
I’ve awarded points to the answer which was most relevant to my original question, although it isn’t the one which was upvoted the most

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    One tends to hit this kind of problem in distributed systems design. It surfaces in Web Service (the WSDL defining the paramers and return types) Messaging systems where the formats of messages might be XML or some other well-defined format. The problem of controlling the coupling of client and server remains in all cases.

    What happens with your hash table? Suppose your request contains “NAME” and “PHONE-NUMBER”, and suddenly you realise that you need to differentiate “LANDLINE-NUMBER” and “CELL-NUMBER”. If you just change the hash table entries to use new values, then your server needs changing at the same time. Suppose at this point you don’t just have one client and one server, but are perhaps dealing with some kind of exchange or broker systems, many clients implemented by many teams, many servers implemented by many teams. Asking all of them to upgrade to a new message format at the same time is quite an undertaking.

    Hence we tend to seek back-comptible solutions such as additive change, we preserve “PHONE-NUMBER” and add the new fields. The server now tolerates messages containg either old or new format.

    Different distribution technologies have different in-built degrees of toleration for back-compatibility. When dealing with serialized classes can you deal with old and new versions? When dealing with WSDL, will the message parsers tolerate additive change.

    I would follow the following though process:

    1). Will you have a simple relationship between client and server, for example do you code and control both, are free to dictate their release cycles. If “no”, then favour flexibility, use hash tables or XML.

    2). Even if you are in control look at how easily your serialization framework supports versioning. It’s likely that a strongly typed, serialized class interface will be easier to work with, providing you have a clear picture of what it’s going to take to make a change to the interface.

    • 0