People (read components) can use Network.globals to create global data. At the same time the javadoc contains a warning to use it sparingly (fat coupling) and to not use it for component to component communication.
Could you elaborate on the use and meaning of Network.globals? Do you know of anyone using this? (our components do not use it).
There are a couple of scenarios where this could be useful - probably the most common is where one component builds a table, and when it is complete, puts the reference into a named global field, after which other components can reference it in read-only mode.
I agree this facility could be misused, but I have always felt that FBP should not be used by people who have not had training in its use. If you think of most trades other than ours, that is true - you wouldn't want a bridge to be built by a kid who has simply read the manual :-) but in computer programming we do exactly that... and I guess the question is: how do you stop them?! Maybe we could have an apprentice level, journeyman level and expert level! Any thoughts?
Well, actually, the global facility might be the culprit here, not the user. The best way for component to component communication is through IP's. So I am not too happy with this facility.
That is why I started querying you about it and its use.
Rereading your post, I think I understand your intentions. I also think that people will use it in all ways possible, including the less desirable ones.
In your example the other components could start modifying the underlying objects. Even though the container is sufficiently protected with locks, the underlying objects are not.
I still think that any sharing of data should go through the "proper channels" i.e. IP's. Multithreading is much more complex if you allow for general sharing of stuff. Using IP's this is not so much an issue.
What do you think?
" I also think that people will use it in all ways possible, including the less desirable ones." Good point!
We only introduced this function in our production (IBM mainframe) systems after several years - so it wasn't an essential function. I would have no problem replacing the code with either a message saying "this function has now been deprecated due to possibility of improper use" - or what about arranging for Eclipse to protest (loudly) at compile/link time, using annotations (?) but then allow them to run...? Whatever you think!
PS If we do the former, and some people's code no longer runs, it's their fault for not having notified us that they were using it! ;-)
Thanks for your feedback: I agree. The second option would entail influencing the checks in their eclipse, assuming they use eclipse at all. I suspect deprecating the function followed by removal at a later date is the best option. I think with the @deprecated we can add comment, why and how to replace. And one or two versions later, we remove.
What I am interested in is, why you introduced this option on the mainframe? What was your rationale?
Kind regards, Guus.
As I said above, probably the most common scenario is where one component builds a table, and when it is complete, puts the reference into a named global field, after which other components can reference it in read-only mode.
Using named globals, the responsibility is on the developer to make sure that the table-building phase is completely separate from the table-using phase. If only one process uses the table, then the builder can just send the table to the user; however, if the table has multiple users, IMO it's hard to come up with a clean(er) way to manage this. So I wouldn't know what to suggest as an alternative solution! And, if we force them to jump through hoops to achieve this result, it's going to tend to turn them off FBP (that's my experience, anyway).
Don't we have a component to copy packets multiple times? To me that would be a pretty simple solution to sharing the contents (readonly) with multiple readers.
Well yes, but it clutters up the network. What if there are lots of shared read-only tables?
In that case we need to find a solution that works for 1 update, many reads without causing the same trouble as a general global map, where people can cause all kinds of mayhem due to concurrency and such.
Probably, if the problem really exists, there is a way to service just that need. However, at the moment I feel the real problem is the we have no idea who our users are, let alone what they need.
Maybe we need more information about who the users are and how they use the system.
I have read up on deprecated and I found the information I need. If I prepend each method that accesses the globalMap -- one getter, one setter -- with @Deprecated, then every compiler that is worth its salt, will provide explicit warnings on compilation. It doesn't matter whether the programmer uses eclipse or not.
In the Javadoc I include the annotation @deprecated (small caps first character), with comment on the alternative. In that comment I propose using IP's and for multiple output ports I am to write a component that will repeat the input IP to all connected output IP's.
This way, every user is alerted, but old code still runs. The warning does tell them that the globalMap will disappear one of the following releases.
I did not check in yet, because my version of Network does not work. I am upsetting the structure of deadlock detection (see other thread for more information). So you cannot check the javadoc comment yet. I will let you know when you can.
That should cover it all.
Sounds good! Thanks!
Log in to post a comment.