Counting a message queue

[Alexander Vermeulen]

For a project we are building an asynchronous communication with another system. For this communication we are using a message queue.
In system A an user creates a plan and save’s this plan. After this save a messages is put on a message queue. After that system A is finished.

System B periodicaly takes the messages from the queue and does some things based on the plan information.

My question is: how to count the message-queue seen from system A we are building. Is this an ILGV, or is should we see it as an UF?

[Ian Alyss]

I don’t think it can be an ILF. The message is something you don’t intend to store and maintain.
I would count it as EO, because its intention is to give a message to system B that there is a plan with which system B is supposed to do something.
From a logical perspective sending an e-mail, or pushing a message over an interface are all technical implementations of similar requirements.

Hope this helps.

Ian

[Alexander Vermeulen]

So you see the Message-queue just like a mail-server: a technical part for delivering a message.
In that case, I agree, we should see the message as an EO (UF in Dutch).
That’s the easy way out.

But the message / message queue isn’t just a send and forget mechanisme.
System A puts the message in the queue, System B reads and deletes the message from the queue.
The user want’s an alert if there are more then 10 messages in the queue (which is a signal that system B isn’t doing its job).

If we say that the message should be put in a database-table by system A. And that system B should read from this database-table, than the database-table should be counted as an ILF for system A. Do you agree?
But when i tell you that the message is in a message-queue, we wouldn’t count it? Why not?
If system B is not working, than the message-queue is just a system for storing data as long as needed. Just like a database-table.

[EdwinvanGorp]

I agree with Alexander. The message is something you definately intend to store! This makes the queue an ILF from system A’s point of view.

BTW: the queue is also an ILF from system B’s point of view…

[Willem Naber]

I do not agree with you both: the main rule for ILF’s (ILGV’s) is:

a logical group of permanent data (POV of user) complying to both of the following criteria:

Used by applicable system

Maintained by applicable system

Maintaining is not defined as: “store and never touch again”, but as “store and/or change and/or delete”. That last part is important. Only inserting is not maintaining a message. Logically only insert without the possibility of ever change and/or delete cannot be seen as different from an EO (UF).
Apart from that I have serious doubts about the persistent character of a message-queue.

I my opinion the arguments for counting it as EO are much stronger than counting it as ILF.

Excuses, I had to translate the Dutch manual myself, since I do not have the English manual available.

[Alexander Vermeulen]

Maintaining is not defined as: “store and never touch again”, but as “store and/or change and/or delete”. That last part is important. Only inserting is not maintaining a message.

I agree, as it is in the handbook, that something is an ILF when it stores and/or changes and/or deletes data.
But the function has only to be doing one of these: store and/OR change and/OR deletes!
As far as i know a function that create log records in a database table is an IF and the database log table is an ILF.
There is nothing mentioned in the handbook of this log table also must have change and/or delete functions to be an ILF.

So i don’t agree with you that for this rule in the handbook, this won’t be an ILF.
Maybe you have some other convincing rule?

[Willem Naber]

Maintaining is not the case here: once created you cannot change the message. So it is no maintenance. Inserting is part of maintenance. And yes you are inserting. But after the insertion you are done, you cannot change, you cannot delete, the message is no longer maintainable. It is “maintained” at the moment of creation, but directly after that it is no longer maintainable.
In my opinion, it is only maintainable if it remains maintainable. And that is not the case here.

[Alexander Vermeulen]

In my opinion, it is only maintainable if it remains maintainable.
This way, Willem, in your opinion, the log-table in my other example isn’t an ILF also?
An audit-log created with data who done what and when is created once, to be never changed and never deleted (the controller won’t like that).
So that, in your opinion, isn’t an ILF?
Please point me to the right sentence in the handbook where this “remains maintainable” is clarified.
When I read 5.2d there is says “expect one input function, one output function OR one request function per ILF”. So the handbook says the maintainability of an ILF isn’t defined by the number of functions doing the maintenance, One is enough.

[Willem Naber]

Yes, indeed. I have never seen audit trials/logging that are independent of the user-data. I see 1:1 and 1:N relations, when I see optionals in audit trails/logging I would be extremely suspicious. Audit trails/logging will lead to more RET/DET’s, but not to more ILF’s.
An insert on the user-data will mean in the same action also an insert on the audit trail, it can never be independent. If it would be independent, It would also have to be possible to do only an insert in the audit trail. Which is like doping: illegal and fraud.

There is not remark on “remains maintainable”, but there is one thing that you didn’t mention: A message-queue is similar to an outputfile: you write data to the file (or queue), that data cannot be changed. The file (or queue) is picked up by another function (in the same system or another system) and is than processed. The file (or queue) is obsolete after that action.

So I maintain my view that I would not count an ILF and an EI, but only an EO in this case.

[Alexander Vermeulen]

The audit-log example is clouding our main topic. Let’s go back to the first question.

Sentence A: System 1 stores data, System 2 reads this data and deletes it afterwards.
I think sentence A contains an ILF for system 1 and for system 2 as both changes the data.

Sentence B: System 1 stores data in a database-table, System 2 reads data from this database-table and deletes it afterwards.
I think sentence B also contains a ILF for system 1 and for system 2 as both changes the data.

Sentence C: System 1 stores data in a message-queue, System 2 reads data from this message-queue and deletes it afterwards.
As FPA is technic independent, i think changing the word from database-table to message-queue should make no difference and we can also should count a ILF for that case.

[Willem Naber]

Situation 0: System 1 creates a file, System 2 reads the file. File is not further used. Is that also an ILF?

Is system 2 actually removing the message from the Queue? Because I know that a message queue is read, and then the message is gone. I really done know any system that reads a message, processes what needs processing, is done with the action, and then physically removes the message.
I only know applications that read messages from the message queue, and after that the message is gone.

Do you have the 2 separate actions: read message queue and process, and afterwards physically remove the message from the queue?

Edit: And is that required this way by the user?

[Alexander Vermeulen]

We are starting to understand each other and now we come to my point… 🙂
Are we going to ask all kind of technical questions or do we stick to the user-requirements?
If we have sentence A from the user-requirements and there is no choice for the technical solution how to solve these requirements.
Can we count FP?
Yes,I think we can en we should count this data als an ILF for system 1 and 2.
And if we agree on that, why should the FP change when a technical solution is made by using a database, a queue, a file, a xml, ….

[Author]

Posts