Είναι το REST API πάντοτε κατάλληλο για τη βιομηχανία; Πότε είναι προτιμότερο να επιλέξετε ουρές, brokers και επικοινωνία βασισμένη σε συμβάντα;

Το ερώτημα αν το REST API είναι κατάλληλο για τη βιομηχανία δεν αφορά πλέον μια διαφωνία για το προτιμώμενο στυλ ενοποίησης, αλλά μια απόφαση για το πού θα επωμιστεί το έργο το κόστος, την καθυστέρηση και την επιχειρησιακή ευθύνη. Σε βιομηχανικό περιβάλλον, η διεπαφή επικοινωνίας παύει πολύ γρήγορα να είναι απλώς ένα «τεχνικό επίπεδο» και αρχίζει να επηρεάζει τη συνέχεια της διεργασίας, την επαναληψιμότητα των ενεργειών, τη δυνατότητα ελέγχου και τον τρόπο αντίδρασης στις αστοχίες. Το REST λειτουργεί καλά εκεί όπου αναμένουμε μια απλή κλήση, μια σαφή απάντηση και καθαρό έλεγχο της κατάστασης του αιτήματος. Το πρόβλημα αρχίζει όταν το σύστημα πρέπει να συνεχίσει να λειτουργεί παρά την προσωρινή μη διαθεσιμότητα κάποιου από τους συμμετέχοντες, όταν τα μηνύματα πρέπει να παραδίδονται με επιβεβαίωση ή όταν ένα γεγονός πρέπει να προκαλεί συνέπειες σε αρκετούς ανεξάρτητους τομείς. Τότε η επιλογή ανάμεσα σε ένα σύγχρονο αίτημα και σε ουρά, broker και επικοινωνία βασισμένη σε γεγονότα παύει να είναι τεχνικά ουδέτερη.

Αυτό έχει ιδιαίτερη σημασία σήμερα, επειδή όλο και περισσότερα βιομηχανικά έργα συνδέουν τον έλεγχο, τη συντήρηση, τα συστήματα ποιότητας, την αναφορά παραγωγής και τις εξωτερικές υπηρεσίες σε μία ενιαία αλυσίδα εξαρτήσεων. Αν η αρχιτεκτονική βασιστεί αποκλειστικά σε σύγχρονες κλήσεις, η ομάδα συχνά καταλήγει με ένα σύστημα που φαίνεται απλό, αλλά είναι εύθραυστο όταν αυξάνεται ο αριθμός των ενοποιήσεων, όταν το δίκτυο είναι ασταθές ή όταν απαιτείται αυστηρό ίχνος γεγονότων. Το κόστος αυτής της απόφασης δεν φαίνεται στο στάδιο της επίδειξης λειτουργιών, αλλά αργότερα: στο μπλοκάρισμα διεργασιών από ένα μη διαθέσιμο στοιχείο, στη δύσκολη ανασύνθεση της πορείας ενός συμβάντος, στη χειροκίνητη συμφωνία καταστάσεων μεταξύ συστημάτων και στις διαφωνίες για το αν μια ενέργεια εκτελέστηκε ή απλώς δόθηκε ως εντολή. Για τον ιδιοκτήτη προϊόντος και τον υπεύθυνο έργου, το πρακτικό κριτήριο είναι απλό: πρέπει να αποφασιστεί αν η συγκεκριμένη ανταλλαγή δεδομένων έχει χαρακτήρα «ερώτηση–απάντηση εδώ και τώρα» ή μάλλον «καταχώρισε το γεγονός και διασφάλισε την περαιτέρω διαχείρισή του ακόμη και υπό διαταραχές». Από αυτή την απάντηση εξαρτάται όχι μόνο η τεχνολογία, αλλά και το μοντέλο ευθύνης μεταξύ των ομάδων.

Στην πράξη αυτό φαίνεται καθαρά στα συστήματα μηχανών, όπου μία ενέργεια χειριστή ή ένα γεγονός της διεργασίας πρέπει να καταγραφεί, να διαβιβαστεί και να επιβεβαιωθεί σε πολλά σημεία. Αν η εφαρμογή εποπτείας στέλνει σύγχρονα αιτήματα σε διαδοχικές υπηρεσίες και περιμένει το πλήρες σύνολο απαντήσεων, τότε ένα προσωρινό πρόβλημα σε ένα μόνο στοιχείο μπορεί να σταματήσει ολόκληρη την ακολουθία, παρότι μέρος των επιχειρησιακών συνεπειών θα έπρεπε να προκύψει ανεξάρτητα. Αντίθετα, ένας broker ή μια ουρά επιτρέπουν να διαχωριστεί η στιγμή αποδοχής της πληροφορίας από τη στιγμή επεξεργασίας της, να διατηρηθεί το ίχνος του γεγονότος και να ελέγχεται ευκολότερα η επανάληψη μετά από σφάλμα. Αυτό δεν σημαίνει ότι η επικοινωνία βασισμένη σε γεγονότα είναι πάντα καλύτερη: αν απαιτείται άμεση απόφαση που μπλοκάρει την περαιτέρω κίνηση της μηχανής ή αν ο χειριστής πρέπει να λάβει αμέσως δεσμευτική απάντηση, ένα ασύγχρονο μοντέλο χωρίς καλά σχεδιασμένες ενδιάμεσες καταστάσεις μπορεί να αυξήσει την αβεβαιότητα. Γι’ αυτό, ήδη από την αρχή του έργου, αξίζει να μετρώνται όχι μόνο ο χρόνος απόκρισης, αλλά και ο αριθμός των χαμένων ή διπλών μηνυμάτων, ο χρόνος συμφωνίας αποκλινουσών καταστάσεων και η δυνατότητα ανασύνθεσης της ακολουθίας γεγονότων μετά από ένα συμβάν.

Το ζήτημα αυτό συνδέεται φυσικά με την αξιολόγηση κινδύνου στα βιομηχανικά έργα, επειδή η επιλογή του τρόπου επικοινωνίας επηρεάζει τη συνέπεια ενός σφάλματος, την ανιχνευσιμότητα των αποκλίσεων και τη δυνατότητα εφαρμογής αποτελεσματικών μέτρων περιορισμού του κινδύνου. Αν μέσω της διεπαφής περνούν λειτουργίες των οποίων η εσφαλμένη εκτέλεση μπορεί να οδηγήσει σε ακούσια εκκίνηση, επικίνδυνη αλλαγή κατάστασης ή απώλεια ελέγχου της ενέργειας, τότε το θέμα παύει να είναι αποκλειστικά πληροφορικό και περνά στον τομέα του σχεδιασμού του συστήματος της μηχανής και της αξιολόγησης των μέτρων προστασίας. Σε αυτό το σημείο εμφανίζεται και το όριο από το οποίο και μετά πρέπει να εξετάζονται συναφή ζητήματα, μεταξύ των οποίων η προστασία από ακούσια εκκίνηση καθώς και η πρακτική αξιολόγηση κινδύνου σύμφωνα με το ISO 12100. Με άλλα λόγια: η απόφαση για REST, ουρά ή broker δεν πρέπει να λαμβάνεται μετά το demo της ενοποίησης, αλλά όταν η ομάδα είναι σε θέση να ορίσει τη συνέπεια ενός εσφαλμένου ή καθυστερημένου μηνύματος για τη διεργασία, την ασφάλεια και τη λογοδοσία των ενεργειών.

Πού αυξάνεται συχνότερα το κόστος ή ο κίνδυνος

Οι περισσότερες λανθασμένες αποφάσεις δεν προκύπτουν από την επιλογή «λάθος τεχνολογίας», αλλά από την ανάθεση στο REST API καθηκόντων για τα οποία δεν έχει σχεδιαστεί. Στη βιομηχανία, το κόστος αυξάνεται όταν μια διεπαφή αίτημα–απάντηση καλείται να μεταφέρει επικοινωνία ευαίσθητη σε προσωρινή μη διαθεσιμότητα, στη σειρά των γεγονότων ή στην ανάγκη αξιόπιστης επιβεβαίωσης εκτέλεσης. Αν το σύστημα χρειάζεται μόνο να διαβάσει την τρέχουσα κατάσταση μιας συσκευής ή να δεχθεί μια εντολή της οποίας η απουσία μπορεί εύκολα να εντοπιστεί και να επαναληφθεί χωρίς παρενέργειες, το REST μπορεί να είναι επαρκές. Αν όμως το αποτέλεσμα εξαρτάται από το αν το μήνυμα έφτασε ακριβώς μία φορά, με τη σωστή σειρά και με δυνατότητα ανασύνθεσης του ιστορικού μετά από συμβάν, τότε το κόστος παράκαμψης των περιορισμών του REST ξεπερνά γρήγορα τη φαινομενική απλότητα της υλοποίησης. Στην πράξη αυτό σημαίνει πρόσθετη λογική επαναλήψεων, ιδιόκτητους μηχανισμούς προσωρινής αποθήκευσης, συμφωνία αποκλινουσών καταστάσεων και δυσκολότερη απόδοση ευθύνης όταν η συσκευή εκτέλεσε μια λειτουργία αργότερα από το αναμενόμενο ή την εκτέλεσε δύο φορές.

Στο στάδιο του σχεδιασμού, το πρόβλημα συνήθως φαίνεται αθώο: η ομάδα θεωρεί δεδομένα ένα σταθερό δίκτυο, τη συνεχή διαθεσιμότητα των υπηρεσιών και μια σαφώς ορισμένη κατάσταση και στις δύο πλευρές της διασύνδεσης. Στο βιομηχανικό περιβάλλον, αυτές οι παραδοχές σπάνια διατηρούνται για πολύ. Εμφανίζονται διακοπές επικοινωνίας, επανεκκίνηση συσκευής, ενημέρωση ενός ενδιάμεσου συστήματος ή, μερικές φορές, απλώς υπερφόρτωση κατά τις ώρες αλλαγής βάρδιας στην παραγωγή. Τότε, μια αρχιτεκτονική που βασίζεται αποκλειστικά σε σύγχρονες κλήσεις αρχίζει να μεταφέρει τον κίνδυνο στις εφαρμογές και στους χειριστές. Το κόστος του έργου αυξάνεται όχι μόνο λόγω διορθώσεων στον κώδικα, αλλά και εξαιτίας δοκιμών αποκατάστασης, πρόσθετων λειτουργικών διαδικασιών και διαφωνιών για το ποια πλευρά «όφειλε να γνωρίζει» ότι το αίτημα δεν εκτελέστηκε. Το πρακτικό κριτήριο για τη λήψη απόφασης είναι απλό: αν η μη διαθεσιμότητα του παραλήπτη δεν επιτρέπεται να σταματήσει τον αποστολέα και το μήνυμα πρέπει να αποθηκευτεί με ασφάλεια και να εξυπηρετηθεί αργότερα, τότε πρέπει να εξεταστεί σοβαρά η χρήση ουράς, broker ή επικοινωνίας βασισμένης σε συμβάντα αντί για καθαρό REST.

Ένα καλό παράδειγμα είναι η ενοποίηση ενός εποπτικού συστήματος με μια γραμμή, όπου ένα σύστημα δίνει εντολή αλλαγής συνταγής και αρκετά άλλα πρέπει να αποδεχθούν αυτή την αλλαγή, να την επιβεβαιώσουν και να την εφαρμόσουν στη σωστή στιγμή του κύκλου. Με το REST είναι εύκολο να υλοποιηθεί μια κλήση τύπου «ορισμός παραμέτρων», αλλά είναι δυσκολότερο να διασφαλιστεί ότι όλα τα εμπλεκόμενα στοιχεία έλαβαν την ίδια πληροφορία, ότι ένα παλαιότερο μήνυμα δεν θα αντικαταστήσει ένα νεότερο και ότι, μετά από βλάβη, θα είναι δυνατό να διαπιστωθεί ποιος είδε ποια εντολή. Ένας broker συμβάντων ή μια ουρά οργανώνει αυτό το πρόβλημα διαφορετικά: το μήνυμα γίνεται ένα μόνιμο γεγονός μέσα στο σύστημα, το οποίο μπορεί να ιχνηλατηθεί, να υποβληθεί σε εκ νέου επεξεργασία και να ανακτηθεί ανεξάρτητα από πολλούς παραλήπτες. Δεν πρόκειται για επιλογή αποκλειστικά τεχνικής φύσης. Από αυτήν εξαρτάται αν, σε περίπτωση παραπόνου για παρτίδα, διακοπής λειτουργίας ή συμβάντος, μπορεί να αποδειχθεί η ακολουθία των αποφάσεων του συστήματος και, κατά συνέπεια, να αποδοθεί συμβατική, λειτουργική ή εσωτερική ευθύνη. Εκεί όπου η λογοδοσία έχει σημασία, αξίζει να μετριέται όχι μόνο η καθυστέρηση της απόκρισης, αλλά και ο αριθμός των μηνυμάτων που απαιτούν επανάληψη, ο χρόνος συμφωνίας της κατάστασης μετά από βλάβη και η δυνατότητα ανασύνθεσης της ακολουθίας των συμβάντων χωρίς χειροκίνητη ανακατασκευή από πολλά αρχεία καταγραφής.

Αυτό το ζήτημα περνά στο πεδίο της αξιολόγησης κινδύνου σύμφωνα με το ISO 12100 όταν ένα εσφαλμένο ή καθυστερημένο μήνυμα μπορεί να αλλάξει τη συμπεριφορά της μηχανής, της διεργασίας ή ενός προστατευτικού μέσου. Σε μια τέτοια περίπτωση, δεν αρκεί πλέον το ερώτημα της ευκολίας της διασύνδεσης· πρέπει να αξιολογηθούν οι συνέπειες, η ανιχνευσιμότητα και η δυνατότητα περιορισμού των επιπτώσεων, κάτι που είναι συνεπές με την πρακτική που είναι γνωστή από το ISO 12100. Αν η επικοινωνία αφορά λειτουργίες σχετικές με την ασφάλεια, αλληλοασφαλίσεις, συνθήκες εκκίνησης ή επιβεβαιώσεις της κατάστασης ενέργειας, το όριο της σχεδιαστικής ευθύνης μετατοπίζεται από το επίπεδο της εφαρμογής στο επίπεδο ολόκληρου του συστήματος της μηχανής. Αντίστοιχα, και στα συστήματα ενεργοποίησης, συμπεριλαμβανομένων των υδραυλικών, μια εσφαλμένη παραδοχή ότι η πληροφορία θα παραδοθεί έγκαιρα μπορεί να συγκρούεται με τις αρχές σχεδιασμού των προστατευτικών μέσων και των ασφαλών καταστάσεων, κάτι που οδηγεί φυσικά σε ζητήματα που συνδέονται με το ΕΛΟΤ EN ISO 4413. Με άλλα λόγια, οι ουρές και οι broker δεν είναι «καλύτεροι εξ ορισμού», αλλά γίνονται η σωστή επιλογή εκεί όπου ο σχεδιασμός πρέπει να αντέχει σε αστοχία της επικοινωνίας χωρίς απώλεια ελέγχου, ιστορικού και ευθύνης για τις ενέργειες που εκτελέστηκαν.

Πώς να προσεγγίσετε το θέμα στην πράξη

Στην πράξη, το ερώτημα δεν είναι αν το REST API είναι καλό ή κακό, αλλά αν ταιριάζει με τις συνέπειες του σφάλματος, της καθυστέρησης και της έλλειψης απόκρισης στη συγκεκριμένη βιομηχανική διεργασία. Αν η επικοινωνία χρησιμοποιείται κυρίως για ανάγνωση δεδομένων, έναρξη διοικητικών ενεργειών ή διασύνδεση με επιχειρησιακά συστήματα, μια διεπαφή αίτημα–απόκριση μπορεί να είναι η απλούστερη και οικονομικότερη λύση. Το πρόβλημα αρχίζει όταν ο σχεδιασμός προϋποθέτει συνέχεια στην ανταλλαγή πληροφοριών παρά την προσωρινή μη διαθεσιμότητα της μίας πλευράς, ανάγκη για οργανωμένη επεξεργασία συμβάντων ή υποχρέωση ανασύνθεσης του ποιος, πότε και με ποια βάση προκάλεσε μια συγκεκριμένη αλλαγή κατάστασης. Σε ένα τέτοιο πλαίσιο, η επιλογή του REST ως προεπιλεγμένου μηχανισμού συχνά μειώνει το αρχικό κόστος, αλλά αυξάνει το κόστος διαχείρισης βλαβών, συμφωνίας της κατάστασης μετά από διακοπή και διερεύνησης ενός συμβάντος. Αυτή είναι η στιγμή κατά την οποία οι ουρές, οι broker και η επικοινωνία βασισμένη σε συμβάντα παύουν να είναι ένα «αρχιτεκτονικό πρόσθετο» και γίνονται εργαλείο περιορισμού του σχεδιαστικού κινδύνου και της λειτουργικής ευθύνης.

Για την ομάδα και τον manager, αυτό σημαίνει ότι η αρχιτεκτονική απόφαση πρέπει να ληφθεί με βάση μερικά μετρήσιμα χαρακτηριστικά της διεργασίας και όχι τις προτιμήσεις του αναδόχου. Το πιο χρήσιμο κριτήριο είναι απλό: πρέπει να καθοριστεί τι πρέπει να συμβεί με το μήνυμα όταν ο παραλήπτης δεν απαντά τη στιγμή της αποστολής. Αν η σωστή απάντηση είναι «τίποτα κρίσιμο, η λειτουργία μπορεί να επαναληφθεί ή να απορριφθεί με ασφάλεια», το REST συνήθως αρκεί. Αν όμως το μήνυμα πρέπει να διατηρηθεί, να παραδοθεί μετά την επανέναρξη της λειτουργίας, να υποβληθεί σε επεξεργασία μόνο μία φορά ή με σειρά που να μπορεί να αποδειχθεί, τότε η σύγχρονη αρχιτεκτονική αρχίζει να αποκλίνει από τις απαιτήσεις της διεργασίας. Αξίζει αυτό να καταγραφεί ήδη στο στάδιο των παραδοχών ως κριτήρια αποδοχής: επιτρεπτός χρόνος μη διαθεσιμότητας του συνεργαζόμενου μέρους, τρόπος επανάληψης, κανόνες αποδιπλοποίησης, δυνατότητα ιχνηλάτησης της συσχέτισης συμβάντων και τρόπος αποκατάστασης της κατάστασης μετά από βλάβη. Χωρίς τέτοιες συμφωνίες, το έργο φαίνεται επιφανειακά να ξεκινά πιο γρήγορα, αλλά αργότερα επιστρέφει με τη μορφή δαπανηρών αλλαγών στη διασύνδεση, διαφωνιών για το εύρος της ευθύνης και λειτουργικών αποκλίσεων που είναι δύσκολο να κλείσουν.

Ένα χαρακτηριστικό παράδειγμα είναι μια γραμμή ή ένα κελί παραγωγής, όπου το ανώτερο σύστημα μεταβιβάζει εντολές και οι ελεγκτές μαζί με τους σταθμούς αναφέρουν την εκτέλεση, τις απορρίψεις, τις εμπλοκές ή τις μεταβάσεις μεταξύ τρόπων λειτουργίας. Αν κάθε συμβάν «ερωτάται» άμεσα μέσω REST, τότε ακόμη και σε μια στιγμιαία απώλεια συνδεσιμότητας εμφανίζεται πολύ γρήγορα απόκλιση ανάμεσα στην πραγματική κατάσταση και σε αυτήν που βλέπει η εφαρμογή. Από την πλευρά της παραγωγής, αυτό καταλήγει σε χειροκίνητη συμφωνία των δεδομένων, από την πλευρά της ποιότητας σε κενό στο ιστορικό της παρτίδας και από την πλευρά της συντήρησης σε αβεβαιότητα για το αν μια συγκεκριμένη εντολή εκτελέστηκε ή απλώς στάλθηκε. Ένας broker με μόνιμη καταγραφή μηνυμάτων δεν λύνει τα πάντα, αλλά ξεκαθαρίζει τις ευθύνες: ο αποστολέας παρέδωσε το συμβάν, το ενδιάμεσο σύστημα το αποθήκευσε, ο παραλήπτης το επιβεβαίωσε ή όχι. Αυτή είναι μια θεμελιώδης διαφορά όταν αναλύονται τα αίτια μιας διακοπής λειτουργίας και όταν πρέπει να διαπιστωθεί αν το σφάλμα προήλθε από τη λογική της διαδικασίας, από αστοχία του δικτύου ή από εσφαλμένη ακολουθία ενεργειών του χειριστή. Γι’ αυτό ακριβώς η επιλογή του μοντέλου επικοινωνίας επηρεάζει όχι μόνο το κόστος υλοποίησης, αλλά και τον χρόνο εκκίνησης, συντήρησης και ελέγχου.

Το ζήτημα αυτό περνά στο πεδίο της πρακτικής αξιολόγησης κινδύνου όταν το μήνυμα δεν είναι πλέον απλώς πληροφορία, αλλά προϋπόθεση για τη λειτουργία της μηχανής, της διαδικασίας ή ενός προστατευτικού μέτρου. Αν η δυνατότητα εκκίνησης, επανέναρξης μετά από στάση, αποδέσμευσης μιας ακολουθίας ή επιβεβαίωσης της ασφαλούς ενεργειακής κατάστασης εξαρτάται από τη σωστή μετάδοση της κατάστασης, τότε η απόφαση για την ολοκλήρωση των συστημάτων γίνεται μέρος μιας σχεδιαστικής απόφασης με μεγαλύτερη βαρύτητα. Σε μια τέτοια περίπτωση πρέπει να αξιολογηθεί όχι μόνο η διαθεσιμότητα της επικοινωνίας, αλλά και οι συνέπειες της απώλειας, της καθυστέρησης, του διπλασιασμού και της εσφαλμένης ερμηνείας της· εδώ εμφανίζεται φυσικά η μεθοδολογία που είναι γνωστή από το ISO 12100. Αντίστοιχα, όπου η επικοινωνία επηρεάζει τις συνθήκες πρόληψης της απροσδόκητης εκκίνησης, το πληροφοριακό επίπεδο δεν πρέπει να αντιμετωπίζεται ως υποκατάστατο των λύσεων που προβλέπονται για την απομόνωση της ενέργειας και την ασφαλή κατάσταση. Εκεί βρίσκεται το όριο στο οποίο το θέμα συνδέεται ήδη με την ανάλυση της προστασίας από απροσδόκητη εκκίνηση και, ευρύτερα, με τον σχεδιασμό του συστήματος της μηχανής πέρα από την ίδια τη λειτουργικότητα. Με άλλα λόγια, το REST είναι κατάλληλο για τη βιομηχανία όταν οι περιορισμοί του γίνονται συνειδητά αποδεκτοί από τη διαδικασία· όταν αυτό δεν ισχύει, καταλληλότεροι γίνονται οι μηχανισμοί ουρών και η επικοινωνία βάσει συμβάντων, επειδή ανταποκρίνονται καλύτερα στις απαιτήσεις συνέχειας, ιχνηλασιμότητας και ελέγχου των συνεπειών μιας αστοχίας.

Τι να προσέξετε κατά την υλοποίηση

Το συνηθέστερο λάθος κατά την υλοποίηση είναι ότι η επιλογή REST API ή επικοινωνίας βάσει συμβάντων αντιμετωπίζεται ως καθαρά τεχνική απόφαση, ενώ στη βιομηχανία πρόκειται για απόφαση με λειτουργικές και οργανωτικές συνέπειες. Το REST δεν παύει να λειτουργεί μόνο και μόνο επειδή χρησιμοποιείται σε περιβάλλον παραγωγής, αλλά αποκαλύπτει πολύ γρήγορα τους περιορισμούς του εκεί όπου το σύστημα πρέπει να απορροφά διακοπές συνδεσιμότητας, ανομοιόμορφο φορτίο, προσωρινή μη διαθεσιμότητα υπηρεσιών και την ανάγκη μεταγενέστερης αναπαράστασης της ακολουθίας των συμβάντων. Αν η αρχιτεκτονική προϋποθέτει ότι κάθε απόκριση πρέπει να έρχεται αμέσως και με την πρώτη προσπάθεια, το έργο γίνεται εύθραυστο. Η συνέπεια είναι συνήθως προβλέψιμη: αυξάνεται το κόστος ολοκλήρωσης, πολλαπλασιάζονται οι μηχανισμοί παράκαμψης και η ευθύνη για μια εσφαλμένη κατάσταση της διαδικασίας διαχέεται μεταξύ των προμηθευτών των συστημάτων. Από την άλλη πλευρά, οι ουρές και οι brokers δεν λύνουν το πρόβλημα αυτόματα· εισάγουν τους δικούς τους κινδύνους, όπως καθυστερημένη επεξεργασία, διπλασιασμό μηνυμάτων, ανάγκη τακτοποίησης της ακολουθίας και πιο σύνθετη παρακολούθηση. Επομένως, το ερώτημα δεν είναι αν το REST είναι πάντοτε κατάλληλο για τη βιομηχανία, αλλά αν η συγκεκριμένη διαδικασία ανέχεται τα χαρακτηριστικά αυτής της μορφής επικοινωνίας χωρίς να μεταφέρει τον κίνδυνο στην παραγωγή, στη συντήρηση και στη συμμόρφωση.

Στο στάδιο του σχεδιασμού αξίζει να υιοθετηθεί ένα απλό κριτήριο αξιολόγησης: τι ακριβώς θα συμβεί στη διαδικασία αν το μήνυμα δεν φτάσει, αν φτάσει δύο φορές ή αν φτάσει αργά. Αν η συνέπεια είναι μόνο μια καθυστερημένη ανανέωση δεδομένων στο σύστημα αναφορών, το REST μπορεί να είναι επαρκές. Αν όμως η έλλειψη απόκρισης μπλοκάρει μια ακολουθία, επιβάλλει χειροκίνητη παρέμβαση, οδηγεί σε απώλεια του ιστορικού εκτέλεσης των λειτουργιών ή δυσκολεύει να διαπιστωθεί ποιος έλαβε μια απόφαση και με ποια βάση, τότε η σύγχρονη αρχιτεκτονική αρχίζει να δημιουργεί κόστος ήδη από το στάδιο της εκκίνησης. Σε μια τέτοια περίπτωση, η επικοινωνία που βασίζεται σε ουρά ή broker συνήθως οργανώνει καλύτερα τις ευθύνες: ο αποστολέας επιβεβαιώνει την παράδοση, ο παραλήπτης επεξεργάζεται με τον δικό του ρυθμό και η ομάδα έχει τη δυνατότητα να παρακολουθεί εκκρεμότητες, επαναλήψεις και σφάλματα. Για τον υπεύθυνο έργου αυτό σημαίνει ότι πρέπει να μετρά όχι μόνο τη διαθεσιμότητα της υπηρεσίας, αλλά και δείκτες όπως ο χρόνος παραμονής του μηνύματος σε εκκρεμότητα, το ποσοστό επαναλήψεων, ο αριθμός των μη τακτοποιημένων μηνυμάτων και ο χρόνος που απαιτείται για την ανασύνθεση του ιστορικού συμβάντων μετά από ένα περιστατικό.

Στην πράξη, το πρόβλημα γίνεται ιδιαίτερα εμφανές εκεί όπου μία ενσωμάτωση αρχίζει να επιτελεί ταυτόχρονα πολλούς ρόλους. Για παράδειγμα: το ανώτερο σύστημα στέλνει μια εντολή σε έναν σταθμό, λαμβάνει επιβεβαίωση εκτέλεσης και ταυτόχρονα καταγράφει μια κατάσταση που καθορίζει την περαιτέρω εκκίνηση της γραμμής. Όσο μιλάμε για ανταλλαγή επιχειρησιακών δεδομένων, μια καθυστέρηση λίγων δευτερολέπτων μπορεί να είναι αποδεκτή. Αν όμως η ίδια διαδρομή επικοινωνίας αρχίζει να επηρεάζει μια εκτελεστική απόφαση μέσα στη διαδικασία, παύει να είναι ένα ουδέτερο πληροφοριακό πρόσθετο. Τότε η λανθασμένη επιλογή μηχανισμού μεταφράζεται όχι μόνο σε κόστος διακοπών λειτουργίας, αλλά και σε ευθύνη για το αν το σύστημα αντιδρά με προβλέψιμο τρόπο σε απώλεια συνδεσιμότητας, επανεκκίνηση υπηρεσίας ή διπλότυπο μήνυμα. Αυτό είναι το σημείο στο οποίο το θέμα περνά φυσικά στον σχεδιασμό του συστήματος της μηχανής πέρα από την ίδια τη λειτουργικότητα: πρέπει να αποφασιστεί ποιες συνέπειες αστοχίας μπορούν να γίνουν ανεκτές και ποιες απαιτούν διαχωρισμό από το επίπεδο ολοκλήρωσης.

Το όριο γίνεται ακόμη πιο κρίσιμο όταν η επικοινωνία αρχίζει να επηρεάζει συνθήκες που σχετίζονται με τη λειτουργική ασφάλεια ή με την αξιολόγηση κινδύνου. Αν η σωστή ανταλλαγή δεδομένων καθορίζει την ικανοποίηση της συνθήκης ασφαλούς κατάστασης, την έγκριση για επανεκκίνηση της λειτουργίας, την επιβεβαίωση της απουσίας επικίνδυνης ενέργειας ή άλλη λειτουργία με προστατευτική σημασία, δεν αρκεί απλώς η καλή πρακτική στην ολοκλήρωση συστημάτων. Τότε πρέπει να αποσαφηνιστεί αν το εξεταζόμενο στοιχείο παραμένει αποκλειστικά στο επίπεδο της πληροφορίας ή αν εντάσσεται πλέον στον σχεδιασμό στοιχείων συστημάτων ελέγχου που είναι υπεύθυνα για λειτουργίες ασφάλειας. Σε αυτό το σημείο προκύπτουν τα κατάλληλα ερωτήματα από το πεδίο του ΕΛΟΤ EN ISO 13849-1 και της πρακτικής αξιολόγησης κινδύνου σύμφωνα με το ISO 12100, αλλά μόνο αφού έχουν οριστεί η λειτουργία και οι συνέπειες της βλάβης. Για την ομάδα αυτό σημαίνει ότι πρέπει να διαχωρίσει όσα μπορούν να εξυπηρετηθούν μέσω ουράς, broker ή REST από όσα δεν επιτρέπεται να βασίζονται αποκλειστικά σε επικοινωνία γενικού σκοπού. Αν αυτό το όριο δεν καθοριστεί από την αρχή, το κόστος επανέρχεται αργότερα με τη μορφή αλλαγών στο έργο, διαφωνιών κατά την παραλαβή και ευθύνης λήψης αποφάσεων που είναι δύσκολο να τεκμηριωθεί.