Update cooling rack

[DharminB]

changes

• Edited CoolingRackAgent.java to increase readability and added verbose variable
• Edited LoadingBayAgent.java to talk to correct order aggregator (the order aggregator of its own bakery and not some random order aggregator)

[DharminB]

@AhmedFaisal95 We have made a few changes to LoadingBayAgent. These were necessary for the agent to integrate with other agents. We have tested this code with 3 stages running simultaneously. I am merging this pull however. We would like you to let us know if these changes are alright with your testing. If you have any queries, please write in #92 and we will try to make the changes ASAP. I have added you as a reviewer in #92 for the same reason.

[af-a]

No problem. We had made this very change on our repository recently (adding the bakery ID to Yellow Pages services), as we started testing with multiple bakeries, to basically all our agents. We just didn't get the chance to update it on upstream yet.

Few points to note though:

• The OrderProcessor agent service type was named "OrderProcessing" to match the one integrated on upstream. Why was it changed to "OrderProcessor", as quoted below? https://github.com/HBRS-MAAS/project/blob/298926414bfbfeb7024e795c3e59e1eeaeaaa5f9/src/main/java/org/maas/agents/LoadingBayAgent.java#L234 Please refer to the integrated order processing agent on develop here.

• In addition, we're also wondering why, for the OrderAggregator part, the bakery ID was inserted in the service name, instead of the type? The service type is what is usually changed, as you did for the OrderProcessor above. Please see below. https://github.com/HBRS-MAAS/project/blob/298926414bfbfeb7024e795c3e59e1eeaeaaa5f9/src/main/java/org/maas/agents/LoadingBayAgent.java#L190-L191

Awaiting your feedback.

[DharminB]

You are right about the order processor. It should be order processing instead.

Regarding the service, we took the assumption that type of an agent would be its class name (for example, customer agent would be of type customer). The name can be something that is unique to that agent (in the whole simulation). That is the reason why order aggregator search was performed that way. With this logic I just realised that order processing agent search is inconsistent. If you know a norm that is being followed, we can change this. However, the names will be misleading then. Meaning name is generally unique while type can be common.

[af-a]

We understand what you mean, but unfortunately this (adding the bakery ID to the service type as well) was a design choice we had made earlier, and changing it would cause us some trouble.

If possible, we would like to retain the use of the bakery ID plus the agent's name for both service name and type, especially for the order aggregator part. We believe this change should not affect any other team since the delivery stage is implemented solely by us.

Accordingly, we will be updating the develop branch with the appropriate fix soon.

Thanks for the feedback.

[DharminB]

Okay. So you will be changing loading bay. That is great. Thank you.

On 07-Jan-2019 9:53 PM, "AhmedFaisal95" notifications@github.com wrote:

We understand what you mean, but unfortunately this (adding the bakery ID to the service type as well) was a design choice we had made earlier, and changing it would cause us some trouble.

If possible, we would like to retain the use of the bakery ID plus the agent's name for both service name and type, especially for the order aggregator part. We believe this change should not affect any other team since the delivery stage is implemented solely by us.

Accordingly, we will be updating the develop branch with the appropriate fix soon.

Thanks for the feedback.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/HBRS-MAAS/project/pull/103#issuecomment-452077915, or mute the thread https://github.com/notifications/unsubscribe-auth/AQb5SFie0Id_zsImLIQgDKTPMIYVEezvks5vA7O6gaJpZM4ZyjaI .