Ενοποίηση πληροφοριακών συστημάτων με χρήση του διαύλου εταιρικής εξυπηρέτησης (ESB)

Μεταξύ των βέλτιστων πρακτικών για την ενοποίηση σύνθετων πληροφοριακών συστημάτων είναι η κατασκευή λογικών μαρτύρων δεδομένων, καθώς και η δημιουργία κεντρικών υποδομών ανταλλαγής δεδομένων με χρήση συστημάτων MDM και εταιρικών λεωφορείων εξυπηρέτησης (ESB, Enterprise Service Bus). Οι λύσεις μας, συμπεριλαμβανομένου του συστήματος ArchiGraph.MDM, είναι κατάλληλες για χρήση ως μέρος του λειτουργικού συστήματος ειδικός σκοπός Astra Linux Special Edition, καθώς και Alt Linux.

Γιατί χρειάζεται ένας δίαυλος ολοκλήρωσης;

Κάθε εταιρεία που χρησιμοποιεί περισσότερα από δύο προϊόντα λογισμικού που λειτουργούν με αλληλοεπικαλυπτόμενα σύνολα πληροφοριών γνωρίζει ποιο είναι το τίμημα της μη επικοινωνίας μεταξύ τους. Οι μη συγχρονισμένες λίστες πελατών ή σειρές προϊόντων και άλλες πληροφορίες μεταξύ ERP, CRM και άλλων εταιρικών εφαρμογών συνεπάγονται συνεχείς απώλειες χρόνου, πόρων και φήμης της εταιρείας. Η μόνη σωστή λύση σε αυτό το πρόβλημα είναι η υλοποίηση ενός διαύλου εξυπηρέτησης επιχειρήσεων (ESB), σε συνδυασμό με ένα κύριο σύστημα διαχείρισης δεδομένων (MDM).

Λύσεις που βασίζονται σε τακτικές μεταφορτώσεις και μετατροπές πληροφοριών (ETL), αρχιτεκτονική προσανατολισμένη στις υπηρεσίες (SOA), παρέχουν μόνο μια προσωρινή λύση σε τέτοια προβλήματα, έχουν πολλά μειονεκτήματα και περιορίζουν την ανάπτυξη της υποδομής πληροφορικής.

Υλοποίηση του διαύλου ολοκλήρωσης

Κατά την εισαγωγή ενός διαύλου ολοκλήρωσης, προκύπτει το καθήκον της χαρτογράφησης (σύγκρισης) της δομής των πληροφοριών για τα ίδια αντικείμενα που υπάρχουν σε διαφορετικά συστήματα πληροφοριών. Είναι απαραίτητο να λυθεί αυτό το πρόβλημα δημιουργώντας ένα κοινό, ουδέτερο σε σχέση με κάθε εφαρμογή, μοντέλο πληροφοριών. Ένα τέτοιο μοντέλο μπορεί να εφαρμοστεί πιο αποτελεσματικά χρησιμοποιώντας σημασιολογικές τεχνολογίες. Για βέλτιστα αποτελέσματα υλοποίησης, απαιτείται ένας επαγγελματίας αρχιτέκτονας δεδομένων για την ανάπτυξη του μοντέλου.

Σημαντικό μέρος του έργου υλοποίησης είναι η υλοποίηση συνδέσμων (διεπαφές προγραμματισμού) για όλες τις εφαρμογές που εμπλέκονται στην ανταλλαγή δεδομένων. Οι ειδικοί μας έχουν εμπειρία στην ανάπτυξη και σύνδεση υποδοχών για ένα ευρύ φάσμα λογισμικού σε διάφορες πλατφόρμες.

Πραγματοποιούμε έργα ενοποίησης μαζί με συνεργάτες που βασίζονται σε λύσεις IBM WebSphere MQ, Integration Service Bus, WSO2 Message Broker, Apache Synapse και Business Semantics bus.

Συχνά ένα έργο για την υλοποίηση ενός διαύλου ολοκλήρωσης πραγματοποιείται ως μέρος μιας γενικής ανασχεδιασμού της αρχιτεκτονικής πληροφοριών της επιχείρησης.

2005

Enterprise Service Bus - μια προσέγγιση «προϋπολογισμού» για την επίλυση προβλημάτων ολοκλήρωσης

Προετοιμάστηκε από: με βάση υλικά από ξένα site
Μετάφραση: Intersoft Lab

Συνεχίζοντας να εξοικειώνουμε τον αναγνώστη με διάφορες προσεγγίσεις για την ενοποίηση, αποφασίσαμε να επικεντρωθούμε σε μια σχετικά νέα και πολύ ελκυστική τεχνολογία - το λεωφορείο εταιρικής εξυπηρέτησης (Enterprise Service Bus, συντομογραφία ESB).

Τι ακριβώς είναι το Enterprise Service Bus και πώς συγκρίνεται με το Enterprise Application Integration (EAI) που συζητήθηκε σε προηγούμενα τεύχη του περιοδικού DWH, OLAP και XML Connoisseurs Club; Σύμφωνα με την καθιερωμένη παράδοση, θα δώσουμε πρώτα τον λόγο σε ειδικούς σε αυτόν τον τομέα.

Οι αναλυτές της Gartner ορίζουν το ESB ως έναν νέο τύπο ενδιάμεσου λογισμικού που ενσωματώνεται λειτουργικότηταάλλοι ήδη υπάρχοντες τύπουςενδιάμεση υποστήριξη. Το Enterprise Service Bus υποστηρίζει υπηρεσίες Ιστού εφαρμόζοντας το πρωτόκολλο SOAP (Simple Object Access Protocol) και χρησιμοποιώντας τη γλώσσα περιγραφής των υπηρεσιών Web Services (WSDL) και την καθολική περιγραφή, ανακάλυψη και ενσωμάτωση (UDDI). Καθολική περιγραφή, ανίχνευση και ενοποίηση). Πολλά λεωφορεία εταιρικών υπηρεσιών υποστηρίζουν επίσης άλλα στυλ επικοινωνίας, συμπεριλαμβανομένης της εγγυημένης παράδοσης και τη δημοσίευση και την εγγραφή. Οι υπηρεσίες που παρέχονται από αυτά τα λεωφορεία έχουν μια «προστιθέμενη αξία» που δεν έχει το ελαφρύ ενδιάμεσο λογισμικό ανταλλαγής μηνυμάτων - παρέχουν επιθεώρηση μηνυμάτων, μετασχηματισμό, δρομολόγηση βάσει περιεχομένου, ασφάλεια, ανακάλυψη υπηρεσιών για αρχιτεκτονική προσανατολισμένη στις υπηρεσίες, εξισορρόπηση φορτίου και εγγραφή. Ορισμένες υπηρεσίες είναι ενσωματωμένες στη βάση του λεωφορείου, ενώ άλλες εκτελούνται σε πρόσθετα. Επιπλέον, τα λεωφορεία υποστηρίζουν XML και άλλες μορφές μηνυμάτων.

Γιατί είναι τόσο ελκυστικό το εταιρικό λεωφορείο εξυπηρέτησης; Πρώτα απ 'όλα, η σχετική φθηνότητα του. Τα προϊόντα ESB τοποθετούνται γενικά ως προσιτές, ή όπως λένε, λύσεις "προϋπολογισμού".

Πράγματι, σήμερα υπάρχει αύξηση της ζήτησης για τεχνολογίες ολοκλήρωσης. Και ενώ νωρίτερα η ανάπτυξη προϊόντων EAI συνδέθηκε με την επίτευξη στρατηγικών στόχων και, ως εκ τούτου, απέδωσε καρπούς μακροπρόθεσμα, τα καθήκοντα που αυτή τη στιγμήοι εταιρείες πρέπει να αντιμετωπίσουν είναι τακτικής φύσης και απαιτούν νέες προσεγγίσεις. Οι "μοντέρνες επιχειρηματικές πραγματικότητες" έχουν επιστήσει την προσοχή σε τομείς όπου οι πωλητές EAI ήταν παραδοσιακά αδύναμοι - μετασχηματισμός, προγραμματισμός με επίκεντρο τους προγραμματιστές (όπως η Java) και ενοποίηση με εξωτερικές τεχνολογίες. Όλα αυτά «προετοίμασαν γόνιμο έδαφος» για την εμφάνιση μιας νέας κατηγορίας προϊόντων - ESB.

Μιλώντας για τις αρετές ενός λεωφορείου εξυπηρέτησης επιχειρήσεων, αξίζει να παραθέσουμε τα λόγια του Roy Schulte, αντιπροέδρου και μέλους του ερευνητικού τμήματος της Gartner: «Το συνηθισμένο λογισμικότο μεσαίο επίπεδο δεν μπορεί πλέον να υποστηρίζει νέες εφαρμογές που χρησιμοποιούν αρχιτεκτονική προσανατολισμένη στις υπηρεσίες (Service Oriented Architecture, συντομογραφία SOA) και αρχιτεκτονική με βάση συμβάντα (Event Driven Architecture, συντομογραφία EDA), υπηρεσίες Web και διαχείριση επιχειρηματικών διαδικασιών. Αυτός είναι ο κύριος λόγος για τον οποίο οι αρχιτέκτονες και οι διαχειριστές συστημάτων πληροφοριών πρέπει να αξιοποιήσουν τις εταιρικές τους υποδομές πληροφοριών με τα ESB».

Ο επικεφαλής αναλυτής της Gartner επισημαίνει ομάδες προμηθευτών ESB. Αναφέρεται στην πρώτη ομάδα προϊόντων ESB, τα οποία τοποθετούνται ως λύσεις ολοκλήρωσης "προϋπολογισμού" που είναι οι πλέον κατάλληλες για την υποστήριξη σύνθετων εφαρμογών και SOA. Η δεύτερη ομάδα είναι προϊόντα που προορίζονται για την αγορά υπηρεσιών Web και, τέλος, τα τελευταία λογισμικό, παρέχοντας υποστήριξη EDA. Σύμφωνα με τον Roy Schulte, η αγορά ESB θα πυκνώσει τα επόμενα χρόνια, λόγω της αυξανόμενης ζήτησης για υπηρεσίες Web και λύσεις πολλαπλών πρωτοκόλλων και συμβάντων.

Είναι ενδιαφέρον ότι σε ορισμένες εταιρείες το ESB δεν αντιμετωπίζεται ως κατηγορία προϊόντων, αλλά ως αρχιτεκτονική. Για παράδειγμα, στην IBM, ένα λεωφορείο εξυπηρέτησης επιχειρήσεων θεωρείται «αρχιτεκτονικό πρότυπο».

Έτσι, μπορούμε να δηλώσουμε ότι δεν υπάρχει ακόμη σαφής ορισμός του τι είναι το ESB. Στην πραγματικότητα, η συζήτηση περιστρέφεται γύρω από δύο ερωτήματα:

1. Είναι το ESB μια αρχιτεκτονική (και μια που δεν χρειάζεται καν να τυποποιηθεί), μια «μονόπλευρη προσέγγιση» ή ένα ανεξάρτητο προϊόν.

   Αν και είναι επωφελές για ορισμένους προμηθευτές που δεν διαθέτουν επί του παρόντος λύσεις εκτός ραφιού να μιλήσουν για το Enterprise Service Bus ως αρχιτεκτονική, η τρέχουσα κατάσταση είναι τέτοια που οι πελάτες χρειάζονται τα προϊόντα τους για να προσφέρουν λειτουργικότητα ESB. Επομένως, θα πρέπει να περιμένουμε αύξηση του αριθμού των προμηθευτών που προσφέρουν δυνατότητες ESB τα επόμενα δύο χρόνια.

2. Ποια είναι η θέση και το μέλλον των προϊόντων ESB, συγκεκριμένα, είναι το business bus service ένα πιο προηγμένο σύστημα ουράς μηνυμάτων που παρέχει απλό μετασχηματισμό XML, καθώς και δρομολόγηση και ανταλλαγή μηνυμάτων ή θα επιτρέψει η χρήση προσαρμογέων εφαρμογών, αυτοματισμού και μοντελοποίησης επιχειρηματικών διαδικασιών Το ESB θα αντικατασταθεί με επιτυχία EAI.

Προς το παρόν, δεν υπάρχουν οριστικές απαντήσεις σε αυτά τα ερωτήματα.

Ωστόσο, αξίζει να τονιστεί ότι ενώ δεν υπάρχει σαφήνεια σχετικά με το Enterprise Service Bus, είναι σαφές ότι η προσέγγιση ανοιχτών προτύπων του ESB μπορεί να μειώσει σημαντικά το κόστος απόκτησης και υλοποίησης.

Σημειώστε ότι η λέξη «υπηρεσία» στον όρο «λεωφορείο εταιρικής εξυπηρέτησης» είναι κεντρική. Έτσι, οι αναλυτές της Forrester Research θεωρούν το ESB ως «ένα στρώμα ενδιάμεσου λογισμικού με το οποίο μπορείτε να έχετε πρόσβαση σε ένα σύνολο βασικών (επαναχρησιμοποιήσιμων) επιχειρηματικών υπηρεσιών». Το SOA επιτρέπει την προβολή των περισσότερων λειτουργιών ως "υπηρεσία" σε έναν δίαυλο υπηρεσιών επιχείρησης που προωθεί, μετασχηματίζει και επικυρώνει δεδομένα εισόδου και εξόδου σε Μορφή XMLπου λαμβάνονται από αυτές τις υπηρεσίες.

ESB και XML

Θα ήταν άδικο αν δεν τονίζαμε τον ειδικό ρόλο της XML - Η XML είναι η βάση για την ενοποίηση. Εάν δεχτούμε ότι η XML είναι περισσότερο ένα «αλφάβητο» παρά απλώς μια γλώσσα, γίνεται σαφές ότι η πλήρης υλοποίηση της ενοποίησης απαιτεί ενορχήστρωση επιχειρηματικών διαδικασιών, διαχείριση μετασχηματισμού XML και επικύρωση και προώθηση μηνυμάτων XML σε ολόκληρο τον οργανισμό. Όλες αυτές οι λειτουργίες αποτελούν τη βάση του Enterprise Service Bus.

Η XML μπορεί να παρέχει μια ολοκληρωμένη αναπαράσταση ενός συνόλου δεδομένων. Η δημοτικότητα αυτής της γλώσσας μπορεί να αποδοθεί στην υψηλή ευελιξία και επεκτασιμότητα της. Πράγματι, η σύνταξη XML σάς επιτρέπει να εκσυγχρονίσετε και να αναπτύξετε εξειδικευμένα σχήματα XML για την επεξεργασία διαφόρων δεδομένων.

Ταυτόχρονα, η ραγδαία αύξηση του όγκου των προς μεταφορά δεδομένων δημιουργεί σοβαρές δυσκολίες στη λειτουργία της εταιρικής δομής πληροφοριών. Έτσι, τα πρώτα έργα ενοποίησης που χρησιμοποίησαν τις δυνατότητες της XML ήταν «ζωντανή» απόδειξη της υπόσχεσης αυτής της γλώσσας, αλλά τώρα υπάρχουν ορισμένα προβλήματα με την αύξηση του αριθμού, του μεγέθους και της πολυπλοκότητας των εγγράφων XML. Οι παρακάτω είναι οι κύριοι λόγοι για τις υπάρχουσες δυσκολίες (ανεπαρκής επεκτασιμότητα):

• Ανάλυση ολόκληρου του εγγράφου: Συνήθως, θέλετε να αναλύσετε ολόκληρα έγγραφα, ακόμα κι αν χρειάζεται να εξαχθεί μόνο ένα τμήμα τους για δρομολόγηση και φιλτράρισμα. Εάν τα έγγραφα γίνουν μεγάλα, ο χρόνος αναμονής αυξάνεται.
• Εκ νέου σάρωση. Τα έγγραφα συχνά αναλύονται εκ νέου - σε κάθε στάδιο της επιχειρηματικής διαδικασίας, με άλλα λόγια, τα ίδια έγγραφα μπορούν να σαρωθούν πολλές φορές. Δεδομένου ότι αυτή η πρακτική απαιτεί εξαιρετικά πόρους, η απόδοση και η απόδοση υποβαθμίζονται.
• Μονόκλωνη εκτέλεση. Σε αυτήν την περίπτωση, το επόμενο βήμα επεξεργασίας δεν μπορεί να ξεκινήσει μέχρι να ολοκληρωθεί το τρέχον. Ως αποτέλεσμα, η καθυστέρηση αυξάνεται επειδή ολόκληρη η διαδικασία εξαρτάται από το πιο αργό βήμα.

Για να ξεπεραστεί η έλλειψη επεκτασιμότητας, συνιστάται η χρήση μιας αρχιτεκτονικής επεξεργασίας που υποστηρίζει τα ακόλουθα χαρακτηριστικά:

• Ροή εγγράφων - Διασφαλίζει ότι τα έγγραφα XML υποβάλλονται σε επεξεργασία καθώς φθάνει κάθε στοιχείο, π.χ. εξασφαλίζει χαμηλή καθυστέρηση. Αυτή η προσέγγιση καθιστά δυνατή την επεξεργασία μεγάλων μηνυμάτων τόσο παραγωγικά όσο και μικρών.
• Επιλεκτική επεξεργασία, η οποία επιτυγχάνει πολύ σημαντική βελτίωση της απόδοσης επεξεργάζοντας μόνο τα σχετικά τμήματα και όχι ολόκληρο το έγγραφο XML.
• Επεξεργασία πολλαπλών νημάτων, στην οποία ο επεξεργαστής διαχειρίζεται την ευθυγράμμιση των βημάτων σε ένα κανάλι, την εκτέλεση μεμονωμένων βημάτων παράλληλα και την εξισορρόπηση φορτίου πανομοιότυπων βημάτων κατά την επεξεργασία πολλών θραυσμάτων XML.
• Η μόνη σάρωση στην οποία, αντί για πολλές επαναλαμβανόμενες αναγνώσεις της δομής του ίδιου εγγράφου από την αρχή, εξάγονται όλα τα απαραίτητα θραύσματα σε μία μεταφορά.

Οι παραπάνω λειτουργίες μπορούν να υλοποιηθούν χρησιμοποιώντας το Enterprise Service Bus - και χωρίς ειδική κωδικοποίηση και διαμόρφωση.

Ποια είναι η διαφορά μεταξύ ενός διαύλου εταιρικής εξυπηρέτησης (ESB) και των μεσιτών μηνυμάτων (όπως το RabbitMQ);

Ως αποτέλεσμα, το πρόβλημα της μη ικανοποιητικής απόδοσης μπορεί να λυθεί.

συμπέρασμα

Κρίνοντας από δημοσιεύσεις σε ξένες εκδόσεις Διαδικτύου και εκτιμήσεις αναλυτών κορυφαίων ερευνητικών εταιρειών, το εταιρικό λεωφορείο εξυπηρέτησης δεν είναι πλέον μόνο νέα τεχνολογίαμε μεγάλες δυνατότητες. Πράγματι, η Gartner προβλέπει ότι το 2005 οι περισσότερες μεγάλες εταιρείες θα χρησιμοποιούν το ESB. Η IDC πιστεύει ότι το λεωφορείο της εταιρικής υπηρεσίας θα πρέπει να «φέρει επανάσταση» ΤΕΧΝΟΛΟΓΙΑ της ΠΛΗΡΟΦΟΡΙΑΣκαι επιτρέπουν την ευέλικτη και επεκτάσιμη κατανεμημένη επεξεργασία.

Πράγματι, η υποστήριξη για ανοιχτά πρότυπα (και ειδικά XML) παρέχει μια φθηνή αλλά αποτελεσματική λύση και εγγυάται γρήγορη απόδοση της επένδυσης, δηλ. Υψηλού βαθμού ROI. Όπως σημειώνει ο Steve Craggs, αντιπρόεδρος του Integration Consortium, «το ESB είναι η βάση για την ενοποίηση, παρέχει ένα ευέλικτο και προσαρμόσιμο περιβάλλον που επιτρέπει τη γόνιμη, επιτυχημένη και συστηματική υλοποίηση έργων ολοκλήρωσης».

Και όμως, η αβεβαιότητα με την ασάφεια του όρου «λεωφορείο εταιρικής εξυπηρέτησης» εξακολουθεί να παραμένει. Σήμερα, το ESB σημαίνει οποιαδήποτε τεχνολογία απαιτείται για την εφαρμογή του SOA. Αυτή ακριβώς είναι η άποψη που έχει η ZapThink, μια εταιρεία που ειδικεύεται στην ανάπτυξη και εφαρμογή αρχιτεκτονικής προσανατολισμένης στις υπηρεσίες. Από την άποψη αυτή, οι αναλυτές του ZapThink προειδοποιούν ότι εάν δεν αναπτυχθεί ένας πραγματικός και συγκεκριμένος ορισμός του λεωφορείου εξυπηρέτησης επιχειρήσεων το 2005, ο όρος ESB "θα εγκαταλείψει για πάντα το λεξικό SOA". Όσο για το ίδιο το SOA, θα συζητηθεί στο επόμενο άρθρο.

Δημοσιεύσεις

1. Η Beth Gold-Bernstein είναι ένα ESB κρίσιμο για το μέλλον σας;
2. Nigel Thomas και Warren Buckley Rise του ESB.
3. Υλικά που δημοσιεύονται στον ιστότοπο της Κοινοπραξίας Ένταξης.

Τι είναι το ESB και το SOA¶

Μια εξαιρετική περιγραφή της σκέψης του συστήματος των συστημάτων
Nick Coghlan, προγραμματιστής Core Python

επίσης διαθέσιμο σε Catala, Deutsch, Αγγλικά, Francais, ιταλικό, Ολλανδία, Πορτογάλοι, τούρκικοςκαι 中文 .

Η συντομογραφία ESB και το σχετικό SOA μπορεί να είναι πηγή σύγχυσης. Το ESB σημαίνει Enterprise Service Bus. SOA - Service Oriented Architecture.

Αυτά τα ονόματα σημαίνουν ελάχιστα, επομένως τα παρακάτω είναι περισσότερα πλήρεις πληροφορίεςσε απλή γλώσσα, χωρίς υπερβολικό εταιρικό λεξιλόγιο.

Όλη η αλήθεια¶

Ας φανταστούμε τι συμβαίνει όταν συνδέεστε στην εφαρμογή front-end της τράπεζάς σας:

1. Το όνομά σας εμφανίζεται
2. Εμφανίζεται το υπόλοιπο του λογαριασμού σας
3. Εμφάνιση των πιστωτικών και χρεωστικών καρτών σας
4. Μπορεί να υπάρχει μια λίστα με τα αμοιβαία κεφάλαιά σας
5. Λαμβάνετε επίσης μια λίστα με τα προυπολογισμένα δάνεια που μπορεί να σας ενδιαφέρουν

Με μεγάλο βαθμό πιθανότητας, μπορούμε να πούμε ότι όλες αυτές οι πληροφορίες ανήκουν διαφορετικά συστήματακαι εφαρμογές, καθεμία από τις οποίες παρέχει δεδομένα μέσω κάποιας διεπαφής (HTTP, JSON, AMQP, XML, SOAP, FTP, CSV ή οποιαδήποτε άλλη):

1. από CRM που τρέχει Linux και Oracle
2. από ένα σύστημα COBOL που λειτουργεί σε κεντρικό υπολογιστή z/OS
3. λένε ότι αυτές οι πληροφορίες προέρχονται από ένα σύστημα mainframe, αλλά αυτοί οι τύποι είναι πολύ σιωπηλοί για να πουν οτιδήποτε άλλο εκτός από το ότι προτιμούν το CSV από οτιδήποτε άλλο
4. από έναν συνδυασμό PHP και Ruby που εκτελείται σε Windows
5. από PostgreSQL, Python και Java που τρέχουν σε Linux και Solaris

Το ερώτημα είναι πώς μπορείτε να κάνετε την εφαρμογή frontend να μιλήσει στα συστήματα 1-5; Λοιπόν, σε καμία περίπτωση.

Αυτό είναι θεμελιώδες για να διασφαλίσουμε ότι τέτοια περιβάλλοντα μπορούν να κλιμακωθούν πέρα ​​από πολλαπλά συστήματα. Δεν τους αναγκάζετε να επικοινωνούν απευθείας μεταξύ τους.

Στο παρακάτω διάγραμμα, κάθε κλήση σε μια υπηρεσία που παρέχεται από άλλο σύστημα αντιπροσωπεύεται από μια γραμμή με διαφορετικό πάχος και στυλ:

Σημειώστε ότι δεν εμφανίσαμε καν διαδικασίες υψηλού επιπέδου (η εφαρμογή 1 καλεί την εφαρμογή 2 και την εφαρμογή 3 ή την εφαρμογή 5 ανάλογα με το αν η προηγούμενη απάντηση από την εφαρμογή 6 ήταν επιτυχής, έτσι ώστε η εφαρμογή 4 να μπορεί αργότερα να λάβει τα δεδομένα που δημιουργήθηκαν από την εφαρμογή 2, αλλά μόνο εάν η εφαρμογή 1 δεν το απαγορεύει, κλπ.).

Επίσης, σημειώστε ότι δεν μιλάμε για διακομιστές - καθένα από τα συστήματα μπορεί να τρέξει σε 10 φυσικούς διακομιστές, επομένως τουλάχιστον 60 φυσικά στοιχεία θα επικοινωνούν μεταξύ τους.

Ωστόσο, ορισμένα ζητήματα γίνονται εμφανή.

Πώς να διαχωρίσετε τις διεπαφές; Πώς να προγραμματίσετε μια λήψη; Πώς συντονίζετε τις ενημερώσεις ή τον προγραμματισμένο χρόνο διακοπής λειτουργίας όταν κάθε εφαρμογή διαχειρίζεται διαφορετικές ομάδες ανάπτυξης, προμηθευτές ή τμήματα και οι μισοί από τους αρχικούς προγραμματιστές έχουν ήδη εγκαταλείψει την εταιρεία;

Αν νομίζετε ότι μπορείτε να διαχειριστείτε 6 εφαρμογές, τι θα λέγατε για 30;

Μπορείτε να χειριστείτε 400; Και από το 2000; Κάθε εφαρμογή μπορεί να είναι το δικό της μοναδικό οικοσύστημα, που απαιτεί μια ντουζίνα διακομιστές ή άλλες συσκευές για να λειτουργήσει, έτσι ώστε να είναι 20.000 κινούμενα μέρη κατανεμημένα σε ηπείρους με κάθε είδους τεχνικά και πολιτιστικά όρια. Και όλα αυτά τα μέρη θέλουν συνεχώς και ασταμάτητα να ανταλλάσσουν μηνύματα όλη την ώρα χωρίς καμία απολύτως διακοπή λειτουργίας. (Θα σας εξοικονομήσουμε το σχήμα.)

Υπάρχει ένα υπέροχο όνομα για αυτήν την κατάσταση - ένα χάος.

Πώς μπορείτε να διορθώσετε την κατάσταση;¶

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

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

Όταν ορίσετε με σαφήνεια αυτά τα δύο σημεία για τον εαυτό σας, μπορείτε να αρχίσετε να σχεδιάζετε ή να επανασχεδιάζετε τα συστήματά σας γύρω από τις υπηρεσίες.

Μια υπηρεσία είναι κάτι ενδιαφέρον, επαναχρησιμοποιήσιμο και ατομικό που παρέχεται από ένα σύστημα σε άλλες εφαρμογές που θέλουν να τη χρησιμοποιήσουν, αλλά η υπηρεσία δεν εκτίθεται ποτέ απευθείας ένας προς έναν. Αυτή είναι η συντομότερη και πιο ουσιαστική περιγραφή όλων των δυνατών.

Εάν μια δεδομένη λειτουργικότητα του συστήματος ικανοποιεί αυτές τις τρεις απαιτήσεις:

• Εγώενδιαφέρον (ενδιαφέρον)
• Rχρησιμοποιήσιμο (επαναχρησιμοποιήσιμο)
• ΕΝΑτομικός (ατομικός)

τότε υπάρχει μεγάλη πιθανότητα το σύστημα να μπορεί και πρέπει να εκτεθεί σε άλλα συστήματα ως υπηρεσία, αλλά ποτέ να μην συνδεθεί απευθείας.

Ας συζητήσουμε την προσέγγιση του IRA με μερικά παραδείγματα.

Μεταβλητός	Σημειώσεις
περιβάλλον	Σύστημα CRM Ηλεκτρικής εταιρείας
Λειτουργικότητα	Επιστρέψτε μια λίστα πελατών που ήταν ενεργοί στην πύλη Self-Service το 3ο τρίμηνο του 2012
Είναι ενδιαφέρον?	Ναι, αρκετά ενδιαφέρον. Αυτό μπορεί να χρησιμοποιηθεί για τη δημιουργία όλων των ειδών χρήσιμων αναφορών και στατιστικών.
Είναι δυνατό	Όχι, όχι τόσο πολύ. Αν και αυτό σας επιτρέπει να δημιουργήσετε
κατ 'επανάληψη	κατασκευές υψηλού επιπέδου, όπως στατιστικές για ολόκληρο το έτος,
χρήση?	είναι σαφές ότι δεν θα το χρειαστούμε αυτό το 2018.
Είναι ατομικό;	Μάλλον ναι. Εάν υπάρχουν ήδη παρόμοιες υπηρεσίες για άλλα τρίμηνα, τότε μπορείτε να δείτε ολόκληρο το έτος.
Πώς να φτιάξετε έναν IRA από αυτό;	Αναγκάστε να λαμβάνετε αυθαίρετες ημερομηνίες έναρξης και λήξης της περιόδου, αντί να προσδιορίζετε μόνο το τρίμηνο. Αναγκάστε να λαμβάνετε αυθαίρετες εφαρμογές, όχι μόνο την πύλη. Δώστε τη δυνατότητα να καθορίσετε την εφαρμογή για λήψη πληροφοριών ως παράμετρο εισόδου.

Μεταβλητός	Σημειώσεις
περιβάλλον	ιστότοπος ηλεκτρονικού εμπορίου
Λειτουργικότητα	Επιστρέψτε κάθε πληροφορία που έχει συλλεχθεί ποτέ για τον καθορισμένο χρήστη
Είναι ενδιαφέρον?	Σε γενικές γραμμές, ναι. Εάν έχετε πρόσβαση στο σύνολο, μπορείτε πάντα να επιλέξετε αυτό που χρειάζεστε.
Είναι δυνατό	Παραδόξως, όχι πραγματικά. Θα είναι μόνο λίγοι
κατ 'επανάληψη	αιτήσεις, εάν υπάρχουν, που θα ενδιαφέρονται
χρήση?	χρησιμοποιήστε απολύτως κάθε πληροφορία.
Είναι ατομικό;	Σιγουρα οχι. Αυτό το τέρας λειτουργικότητας προορίζεται να αποτελείται λογικά από δεκάδες μικρότερα μέρη.
Πώς να φτιάξετε έναν IRA από αυτό;	Χωρίστε σε πολλά μικρότερα μέρη. Σκεφτείτε τι περιγράφει τον αγοραστή - έχει διευθύνσεις, αριθμούς τηλεφώνου, αγαπημένα προϊόντα, προτιμώμενες μεθόδους επικοινωνίας μαζί του και ούτω καθεξής. Κάθε ένα από αυτά τα στοιχεία θα πρέπει να μετατραπεί σε ανεξάρτητη υπηρεσία. Χρησιμοποιήστε το ESB για να δημιουργήσετε σύνθετες υπηρεσίες από ατομικές.

Μεταβλητός	Σημειώσεις
περιβάλλον	Οποιοδήποτε σύστημα CRM, οπουδήποτε
Λειτουργικότητα	Ενημερώστε τη στήλη CUST_AR_ZN στον πίνακα C_NAZ_AJ αφού κάποιος δημιουργήσει έναν λογαριασμό
Είναι ενδιαφέρον?	Εντελώς χωρίς ενδιαφέρον. Αυτή είναι μια εσωτερική λειτουργία του συστήματος CRM. Κανείς με το σωστό μυαλό του δεν θέλει να ασχοληθεί με τόσο χαμηλού επιπέδου λειτουργικότητα.
Είναι δυνατό	Ναι, μάλλον. λογαριασμόςμπορεί να δημιουργηθεί μέσω
κατ 'επανάληψη	πολλά κανάλια, οπότε φαίνεται να είναι κάτι πολλαπλό
χρήση?	μεταχειρισμένος.
Είναι ατομικό;	Φαίνεται ναι. Αυτή είναι μια απλή ενημέρωση μιας στήλης σε έναν πίνακα.
Πώς να ξεχωρίσεις
αυτός ο IRA;	Μην προσπαθήσετε καν να δημιουργήσετε μια υπηρεσία από αυτό. Δεν είναι ενδιαφέρον. Κανείς δεν θέλει να σκεφτεί συγκεκριμένες στήλες και πίνακες σε ένα σύστημα. Αυτό είναι ένα δύσκολο μέρος ενός συστήματος CRM και, παρόλο που είναι επαναχρησιμοποιήσιμο και ατομικό, δεν αξίζει να δημιουργήσετε μια υπηρεσία. Είναι δικό σας και το CRM, είναι δική σας ευθύνη να το σκεφτείτε, μην αναγκάζετε τους άλλους να το υποστούν επίσης

Μεταβλητός	Σημειώσεις
περιβάλλον	Χειριστής κινητής τηλεφωνίας
Λειτουργικότητα	Αναπλήρωση προπληρωμένης κάρτας επικοινωνίας στη χρέωση
Είναι ενδιαφέρον?	Επακρώς. Όλοι θέλουν να το χρησιμοποιήσουν, μέσω μηνυμάτων κειμένου, IVR, IM, πυλών, δωροκάρτεςκαι τα λοιπά.
Είναι δυνατό	Ναί. Μπορεί να λάβει μέρος σε πολλά υψηλού επιπέδου
κατ 'επανάληψη	διαδικασίες.
χρήση?
Είναι ατομικό;	Ναι, από την άποψη της εφαρμογής κλήσης, η κάρτα μπορεί να συμπληρωθεί ή όχι. Το γεγονός ότι η χρέωση το υλοποιεί μέσω μιας σειράς βημάτων δεν είναι σημαντικό. Από επιχειρηματική άποψη, αυτό είναι ατομικό, είναι μια αδιαίρετη υπηρεσία που παρέχεται μέσω τιμολόγησης.
Πώς να ξεχωρίσεις	Είναι ήδη IRA.
αυτός ο IRA;

Εάν έχετε κάνει έστω και λίγο προγραμματισμό τα τελευταία 50 χρόνια, θα σας καταστεί προφανές ότι η παροχή μιας υπηρεσίας είναι σαν να παρέχετε ένα API σε ένα κομμάτι κώδικα για ένα άλλο. Η μόνη διαφορά είναι ότι δεν έχεις να κάνεις με υπομονάδες ενός συστήματος, εργάζεσαι στο επίπεδο ενός ολόκληρου περιβάλλοντος μεμονωμένων συστημάτων.

Διαθεσιμότητα υπηρεσιών σε ESB και SOA¶

Τώρα που γνωρίζετε ότι τα συστήματα δεν επικοινωνούν απευθείας και καταλαβαίνετε τι είναι μια υπηρεσία, μπορείτε να αρχίσετε να χρησιμοποιείτε αποτελεσματικά το ESB.

Τώρα είναι δουλειά του ESB να παρέχει και να επικαλείται υπηρεσίες ολοκληρωμένων συστημάτων. Έτσι, στις περισσότερες περιπτώσεις πρέπει να οριστεί μόνο μία μέθοδος πρόσβασης, μία διεπαφή μεταξύ κάθε συστήματος και του ESB.

Έτσι, εάν, όπως στο παραπάνω διάγραμμα, έχετε 8 συστήματα - τότε έχετε 16 διεπαφές (μία προς κάθε κατεύθυνση) για δημιουργία, συντήρηση, διαχείριση και παροχή.

Χωρίς το ESB, θα είχατε 56 διεπαφές για δημιουργία και διαχείριση (υποθέτοντας ότι κάθε σύστημα συνομιλεί μεταξύ τους).

Χωρίς επιπλέον 40 διεπαφές σημαίνει λιγότερο χαμένο χρόνο και περισσότερα χρήματα εξοικονόμησης. Αυτός είναι ένας από τους λόγους που οι Παρασκευές σας θα είναι λιγότερο αγχωτικές.

Αυτό το γεγονός από μόνο του θα πρέπει να σας παρακινήσει να σκεφτείτε την εφαρμογή ενός ESB.

Εάν ένα από τα συστήματα ξαναγραφτεί, μεταφερθεί σε άλλο ιδιοκτήτη, χωριστεί μεταξύ τμημάτων ή προμηθευτών, τότε θα είναι καθήκον των παιδιών της ESB να κάνουν τις κατάλληλες αλλαγές. Κανένα από τα άλλα συστήματα δεν θα το προσέξει καν αυτό, καθώς η διεπαφή τους με το ESB θα είναι ανέγγιχτη.

Μόλις αρχίσετε να αναπνέετε υπηρεσίες IRA σε τακτική βάση, μπορείτε να αρχίσετε να σκέφτεστε τις σύνθετες υπηρεσίες.

Θυμάστε την παραπάνω υπηρεσία "δώσε-μου-ό,τι-μπορείς-να-κάνεις-σχετικά με αυτόν τον πελάτη";

Δεν ήταν καλή ιδέα να δημιουργήσετε ένα, αλλά μερικές φορές θα συναντήσετε εφαρμογές πελατών που πρέπει να συγκεντρώνουν πληροφορίες. Τα παιδιά της ESB θα είναι υπεύθυνα για αυτό και θα είναι δουλειά τους να επιλέξουν τις καλύτερες ατομικές υπηρεσίες για να δημιουργήσουν μια σύνθετη υπηρεσία για το συγκεκριμένο σύστημα πελάτη που απαιτεί το συγκεκριμένο σύνολο σύνθετων δεδομένων.

Με την πάροδο του χρόνου, ολόκληρος ο οργανισμός θα αρχίσει να συνειδητοποιεί ότι δεν πρόκειται πλέον για πίνακες βάσεων δεδομένων, αρχεία, πακέτα, συναρτήσεις, υπορουτίνες ή εγγραφές. Τώρα μιλάμε για μια αρχιτεκτονική που επικεντρώνεται σε ενδιαφέρουσες, επαναχρησιμοποιήσιμες και ατομικές υπηρεσίες που παρέχονται από εφαρμογές ESB.

Οι άνθρωποι δεν θα πιστεύουν πλέον ότι οι εφαρμογές και τα συστήματα στέλνουν μηνύματα το ένα στο άλλο. Θα δουν το ESB ως μια ενιαία πύλη προς ενδιαφέρουσες υπηρεσίες που μπορούν να χρησιμοποιήσουν τα δικά τους συστήματα. Και δεν θα ελέγξουν καν ποιος παρέχει τι, τα συστήματά τους θα ασχολούνται μόνο με το ESB.

Θα χρειαστεί χρόνος, υπομονή και συντονισμένες προσπάθειες, αλλά είναι εφικτό.

Προσοχή όμως…¶

Πλέον Ο καλύτερος τρόποςκαταστρέψτε ολόκληρη την ιδέα του SOA - αναπτύξτε το ESB και περιμένετε να επιδιορθωθούν τα προβλήματα. Αν και μια εξαιρετική ιδέα, η ανάπτυξη ενός ESB δεν θα είναι αρκετή, δυστυχώς.

Στην καλύτερη περίπτωση, η προσπάθεια να κρύψετε κάτι κάτω από το χαλί, όπως στο παρακάτω διάγραμμα, δεν θα οδηγήσει σε τίποτα:

Οι τύποι πληροφορικής σας θα μισήσουν το σύστημα και ενώ οι διαχειριστές θα ανεχτούν αρχικά το ESB ως μια νέα λύση, τελικά θα γίνει περίγελος. «Τι, είναι αυτή η ίδια νέα ασημένια σφαίρα; Χαχαχα."

Τέτοιες συνέπειες είναι αναπόφευκτες εάν το ESB δεν αποτελεί μέρος ενός ευρύτερου αναπτυξιακού σχεδίου.

Λοιπόν, το ESB είναι μόνο για τράπεζες και άλλα παρόμοια;¶

Καθόλου. το καλή απόφασησε κάθε περίπτωση που απαιτεί τη συντονισμένη εργασία πολλών πηγών δεδομένων και αρκετών μεθόδων πρόσβασης για να επιτευχθεί ένα ενδιαφέρον αποτέλεσμα.

Για παράδειγμα, το έργο της συλλογής των πιο πρόσφατων μετρήσεων θερμοκρασίας και της δημοσίευσής τους σε πολλά κανάλια, όπως ειδοποιήσεις μέσω email και εφαρμογές iPhone, ταιριάζει σε μια πλατφόρμα ενοποίησης.

Ο περιοδικός έλεγχος και παρακολούθηση της λειτουργίας όλων των παρουσιών μιας κρίσιμης εφαρμογής, και αν δεν εκτελούνται όλες, η εκτέλεση ενός διαμορφωμένου σεναρίου και η αποστολή μηνύματος κειμένου στους διαχειριστές είναι επίσης εξαιρετική.

Οτιδήποτε χρειάζεται να ενσωματωθεί σε ένα σαφές, καλά καθορισμένο περιβάλλον είναι πιθανότατα κατάλληλο για μια υπηρεσία ESB. Αλλά, όπως πάντα, η απόφαση για το αν κάτι είναι πραγματικά κατάλληλο για ενσωμάτωση έρχεται με την εμπειρία.

εταιρικό λεωφορείο εξυπηρέτησης

Φυσικά, η ομάδα Zato μπορεί να βοηθήσει.

Αλλά άκουσα ότι το SOA είναι XML, SOAP και υπηρεσίες ιστού¶

Ναι, κάποιοι θα ήθελαν να το πιστεύετε αυτό.

Εάν τα άτομα ή οι προμηθευτές με τους οποίους έχετε συνεργαστεί έστειλαν ένα αρχείο CSV με κωδικοποίηση BASE64 σε ένα μήνυμα SOAP με ασφάλεια SAML2, τότε είναι κατανοητό γιατί έχετε αυτή την εντύπωση.

Το XML, το SOAP και οι υπηρεσίες Ιστού έχουν τις περιπτώσεις χρήσης τους, αλλά όπως όλα τα άλλα, μπορεί να γίνει κατάχρηση.

Το SOA αφορά την κατανοητή και διαχειρίσιμη αρχιτεκτονική. Το αν μια υπηρεσία μπορεί ή όχι να χρησιμοποιεί SOAP είναι πρακτικά άσχετο. Το SOA ως αρχιτεκτονική προσέγγιση θα εξακολουθεί να ισχύει ακόμη και αν δεν χρησιμοποιείται καθόλου υπηρεσία SOAP.

Εάν ένας αρχιτέκτονας σχεδιάζει ένα όμορφο κτίριο, δεν μπορεί να επηρεάσει πάρα πολύ το χρώμα του εσωτερικού.

Άρα όχι, το SOA δεν είναι XML, SOAP και υπηρεσίες web. Μπορούν να χρησιμοποιηθούν, αλλά είναι μόνο ένα μέρος, όχι η βάση.

Μπορείτε να παραπέμψετε τους χαμένους συναδέλφους σε αυτό το άρθρο, ώστε να καταλάβουν τι είναι το SOA.

Περισσότερα¶

Αυτό το κεφάλαιο καλύπτει μόνο τα πολύ βασικά, αλλά θα πρέπει ωστόσο να παρέχει μια σταθερή κατανόηση του πώς θα πρέπει να μοιάζουν το ESB και το SOA και τι χρειάζεται για να είναι επιτυχημένο.

Άλλα θέματα που δεν καλύπτονται εδώ περιλαμβάνουν (αλλά δεν περιορίζονται σε):

• Πώς να λάβετε υποστήριξη από τους διαχειριστές για την εισαγωγή του ESB
• Πώς να συγκεντρώσετε αρχιτέκτονες SOA και ομάδες ανάλυσης
• Αναπαράσταση του Κανονικού Μοντέλου Δεδομένων (CDM) σε έναν οργανισμό
• Βασικοί δείκτες απόδοσης (KPIs) - τώρα που έχετε μια κοινή και ενοποιημένη μέθοδο παροχής υπηρεσιών μεταξύ συστημάτων, θα πρέπει να αρχίσετε να παρατηρείτε και να αναλύετε τι πραγματικά σας παρέχεται
• Διαχείριση Επιχειρηματικών Διαδικασιών (BPM) - πώς και πότε να επιλέξετε μια πλατφόρμα BPM για διαχείριση υπηρεσιών (η απάντηση δεν είναι πολύ γρήγορη, μάθετε πρώτα πώς να δημιουργείτε ωραίες και χρήσιμες υπηρεσίες)
• Τι να κάνετε με συστήματα χωρίς API; Για παράδειγμα, εάν το ESB αποκτήσει άμεση πρόσβαση στις βάσεις δεδομένων του (η απάντηση είναι διαφορετική, δεν υπάρχει χρυσός κανόνας)

Τι είναι λοιπόν ο Zato;¶

Το Zato είναι ένας διακομιστής ESB και εφαρμογών γραμμένος σε Python και μπορεί να χρησιμοποιηθεί για τη δημιουργία ενδιάμεσων προγραμμάτων και συστημάτων υποστήριξης. Αυτό το λογισμικό είναι ανοιχτό πηγαίος κώδικαςμε εμπορική και κοινοτική υποστήριξη. Και η Python είναι μια γλώσσα προγραμματισμού γνωστή για την απλότητα και την αποτελεσματικότητά της.

Η χρήση Python και Zato σάς επιτρέπει να αυξήσετε την παραγωγικότητα και να χάνετε λιγότερο χρόνο.

γράφτηκε ο Ζάτο πραγματιστές για πραγματιστές. Αυτό δεν είναι άλλο ένα βιαστικά κατασκευασμένο σύστημα από έναν πωλητή στον απόηχο της διαφημιστικής εκστρατείας ESB/SOA.

Στην πραγματικότητα, το Zato κατασκευάστηκε από πρακτική εμπειρία στην «κατάσβεση πυρκαγιών» που προκαλούνται από τέτοια συστήματα. Πράγματι, οι συγγραφείς του Zato έχουν αφιερώσει τόσο πολύ χρόνο στην καταπολέμηση τέτοιων περιβαλλόντων που έχουν αποκτήσει ουσιαστικά ανοσία σε τυχόν πυρκαγιές.

Αυτό είναι το σφυρήλατο από το οποίο ήρθε στον κόσμο η Zato και ως εκ τούτου μπορεί να προσφέρει απόδοση και ευκολία χρήσης που δεν συναντώνται σε άλλες παρόμοιες λύσεις.

Θα σε δώ στο εδώ!

(Enterprise Service Bus) έχει σχεδιαστεί για να δημιουργεί ένα τοπίο κατανεμημένων πληροφοριών μιας επιχείρησης. Λογισμικόεξασφαλίζει την αλληλεπίδραση όλων των ολοκληρωμένων εφαρμογών σε ένα κέντρο, συνδυάζοντας υπάρχουσες πηγές πληροφοριών και παρέχοντας μια κεντρική ανταλλαγή δεδομένων μεταξύ διαφορετικών πληροφοριακά συστήματα.

Enterprise Service Data Bus DATAREON ESBείναι ένα αποτελεσματικό μέσο για τη διασφάλιση της σταθερότητας και της πληρότητας της ανταλλαγής πληροφοριών, την αύξηση της συνολικής απόδοσης του πληροφοριακού συστήματος και τη μείωση του κόστους εργασίας για τη διοίκησή του.

Enterprise Service Bus

Λογισμικό DATAREON ESBπεριλαμβάνεται επίσημα στο ενιαίο μητρώο ρωσικών προγραμμάτων για ηλεκτρονικά Υπολογιστέςκαι βάσεις δεδομένων που μπορούν να αγοραστούν από κρατικούς και δημοτικούς φορείς (https://reestr.minsvyaz.ru/).

Για την ενσωμάτωση 2-3 πληροφοριακών συστημάτων σε μικρές εταιρείες, η DATAREON προσφέρει ένα προϊόν λογισμικού που βασίζεται στο DATAREON ESB - DATAREON MQ.

Λειτουργικότητα του DATAREON ESB

Εργασίες που επιλύθηκαν με χρήση του διαύλου δεδομένων εταιρικής υπηρεσίας

• Μεταφορά δεδομένωνμεταξύ διαφορετικών συστημάτων πληροφοριών (δρομολογημένα ή από σημείο σε σημείο)
• Διαμόρφωση ενιαίου χώρου πληροφοριώνσε ετερογενή περιβάλλοντα
• Δημιουργία ενός κατανεμημένου συστήματος με βάση ένα μοντέλο συμβάντωνστις παρακάτω επιλογές:
  • δημιουργία εφαρμογών με επιχειρηματικές διαδικασίες από άκρο σε άκρο με βάση το μοντέλο συμβάντων.
  • δημιουργία συστήματος με συγχρονισμό επιχειρηματικών εφαρμογών σε διάφορα πληροφοριακά συστήματα
• Παραλαβή κλιμακούμενη αρχιτεκτονική ελέγχουεπίπεδο επιχείρησης/εκμετάλλευσης
• Ανάπτυξη συστήματα ανταλλαγής δεδομένωνστο επίπεδο μεταφοράς και σε επίπεδο επιχειρηματικής λογικής
• Ανάθεση του έργου δημιουργίας ροών πληροφοριώναναλυτικά τμήματα
• Μείωση της συνολικής πολυπλοκότητας του συστήματος ένταξηςκαι μειώνοντας την απαίτηση για εύρος ζώνηςκαναλιών
• Αύξηση της συνολικής σταθερότηταςστρώμα μεταφοράς δεδομένων
• Μειωμένο κόστος συναλλαγήςκατά την ανταλλαγή δεδομένων μεταξύ διαφορετικών τμημάτων
• Μειωμένο συνολικό κόστοςσυντήρηση και υποστήριξη του πληροφοριακού συστήματος.

Οφέλη του DATAREON ESB Enterprise Service Bus

• Γρήγορη ενσωμάτωση
• Υψηλή αξιοπιστία
• Δυνατότητα επαναχρησιμοποίησης πόρων

), παλαιότερα γνωστό ως Axelot Datareon ESB, έχει σχεδιαστεί για να δημιουργήσει ένα κατανεμημένο τοπίο επιχειρηματικών πληροφοριών. Το προϊόν λογισμικού διασφαλίζει την αλληλεπίδραση όλων των ολοκληρωμένων εφαρμογών σε ένα κέντρο, συνδυάζοντας υπάρχουσες πηγές πληροφοριών και παρέχοντας μια κεντρική ανταλλαγή δεδομένων μεταξύ διαφορετικών συστημάτων πληροφοριών.

Το Datareon ESB Enterprise Data Service Bus είναι ένα μέσο διασφάλισης της σταθερότητας και της πληρότητας της ανταλλαγής πληροφοριών, αυξάνοντας τη συνολική απόδοση του πληροφοριακού συστήματος και μειώνοντας το εργατικό κόστος για τη διαχείρισή του.

Το προϊόν λογισμικού Datareon ESB περιλαμβάνεται επίσημα στο ενοποιημένο μητρώο ρωσικών προγραμμάτων για ηλεκτρονικούς υπολογιστές και βάσεις δεδομένων, τα οποία μπορούν να αγοραστούν από κρατικούς και δημοτικούς φορείς.

Λειτουργικότητα

• Υποστήριξη για διάφορα πρότυπα και σενάρια ολοκλήρωσης
• Κεντρική διαχείριση του τοπίου ολοκλήρωσης με το οικοσύστημα Eclipse
• Μετασχηματισμός δεδομένων (αλγόριθμοι μετασχηματισμού δεδομένων πολλαπλών βημάτων με έλεγχο διαφόρων συνθηκών)
• Μεταφορά δεδομένων οποιουδήποτε μεγέθους (κάθετη και οριζόντια κλιμάκωση)
• Εύκολη ενσωμάτωση με προϊόντα που βασίζονται στην πλατφόρμα 1C:Enterprise 8
• Εξασφάλιση ασφαλούς μεταφοράς δεδομένων
• Διαγνωστικά και παρακολούθηση της κατάστασης ολόκληρου του δικτύου δεδομένων

Εργασίες που πρέπει να επιλυθούν

• Μεταφορά δεδομένων μεταξύ διαφορετικών συστημάτων πληροφοριών (με δρομολόγηση ή από σημείο σε σημείο)
• Σχηματισμός ενιαίου χώρου πληροφοριών σε ετερογενή περιβάλλοντα
• Δημιουργία ενός κατανεμημένου συστήματος με βάση το μοντέλο συμβάντων στις ακόλουθες επιλογές:
  • δημιουργία εφαρμογών με επιχειρηματικές διαδικασίες από άκρο σε άκρο με βάση το μοντέλο συμβάντων.
  • δημιουργία συστήματος με συγχρονισμό επιχειρηματικών εφαρμογών σε διάφορα πληροφοριακά συστήματα
• Απόκτηση μιας κλιμακούμενης αρχιτεκτονικής διαχείρισης σε επίπεδο επιχείρησης/εκμετάλλευσης
• Ανάπτυξη συστήματος ανταλλαγής δεδομένων σε επίπεδο μεταφορών και σε επίπεδο επιχειρηματικής λογικής
• Ανάθεση του έργου δημιουργίας ροών πληροφοριών σε αναλυτικά τμήματα
• Μείωση της συνολικής πολυπλοκότητας του συστήματος ολοκλήρωσης και μείωση της απαίτησης για εύρος ζώνης των καναλιών
• Αύξηση της συνολικής σταθερότητας του επιπέδου μεταφοράς δεδομένων
• Μείωση του κόστους συναλλαγών κατά την ανταλλαγή δεδομένων μεταξύ διαφορετικών τμημάτων

2017

Axelot Datareon ESB 2.1.0.0

Η λύση AXELOT Datareon ESB συμπεριλήφθηκε στη λίστα δεξιοτήτων Ανάπτυξης Εφαρμογών Gold - γεγονός που επιβεβαιώνει την υψηλή ποιότητα του προϊόντος και τη συμβατότητά του με τα προϊόντα της Microsoft.

Το AXELOT Datareon ESB παρέχει μια σειρά από βασικά οφέλη για τις επιχειρήσεις:

• Δυνατότητα ενσωμάτωσης;
• Αξιοπιστία και επαναχρησιμοποίηση πόρων.
• Απόκτηση μιας κλιμακούμενης αρχιτεκτονικής διαχείρισης σε επίπεδο επιχείρησης/εκμετάλλευσης.
• Ανάθεση του έργου δημιουργίας ροών πληροφοριών σε αναλυτικά τμήματα.
• Μείωση της συνολικής πολυπλοκότητας του συστήματος ολοκλήρωσης και μείωση της απαίτησης για εύρος ζώνης καναλιού.
• Αύξηση της συνολικής σταθερότητας του επιπέδου μεταφοράς μεταφοράς δεδομένων.
• Μείωση του κόστους συναλλαγών κατά την ανταλλαγή δεδομένων μεταξύ διαφορετικών τμημάτων.
• Μείωση του συνολικού κόστους συντήρησης και συντήρησης του πληροφοριακού συστήματος.

Τα κύρια χαρακτηριστικά του συστήματος:

• Ένας μεγάλος αριθμός συνδετήρων διάφορα συστήματα: 1С:Enterprise 8, υπηρεσίες SOAP, υπηρεσίες REST, MS SQL, IBM DB2, Oracle DB, PostgreSQL, SharePoint, OData, TCP, Siemens TeamCenter και άλλα.
• Μηχανισμός plugin για ανεξάρτητη ανάπτυξη συνδέσμων.
• Υποστήριξη για διάφορες γλώσσες προγραμματισμού και τεχνολογίες κατά την ανάπτυξη σεναρίων αλληλεπίδρασης: 1C:Enterprise 8, JavaScript, T-SQL.
• Ρύθμιση σεναρίων μετασχηματισμού δεδομένων πολλαπλών βημάτων χρησιμοποιώντας μηχανισμούς οπτικής χαρτογράφησης και αυθαίρετους μετασχηματισμούς XSLT.
• Δουλεύω με διάφορες μορφέςδεδομένα (XML, JSON, XLS, DBF, CSV, Base64 και άλλα).
• Στατική και δυναμική δρομολόγηση πακέτων πληροφοριών.
• Υψηλή ταχύτητα αλληλεπίδρασης και ανοχή σφαλμάτων: μειωμένες απαιτήσεις για εύρος ζώνης δικτύου, εξισορρόπηση φορτίου, απομόνωση τομέων πληροφοριών, δυνατότητα παρακολούθησης της κατάστασης των κόμβων ολοκλήρωσης.
• Υποστήριξη μοντέλου εκδήλωσης, σύγχρονες και ασύγχρονες κλήσεις, εγγυημένη παράδοση.
• Αλλαγή σεναρίων ολοκλήρωσης συστημάτων συνδρομητών (μηχανισμοί εκφόρτωσης/φόρτωσης, μετασχηματισμού και δρομολόγησης) σε λειτουργία "hot" χωρίς την ανάγκη διακοπής τους (συμπεριλαμβανομένων των διαμορφώσεων στην πλατφόρμα 1C:Enterprise 8).
• Διαγνωστικά και παρακολούθηση όλων των διαδικασιών ολοκλήρωσης, εντοπισμού σφαλμάτων και ιχνηλάτησης πακέτων πληροφοριών.

Ιδιαίτερη προσοχή δίνεται στην ενσωμάτωση εφαρμογών στην πλατφόρμα 1C:Enterprise 8. Η παράδοση περιλαμβάνει ένα ειδικό υποσύστημα που είναι ενσωματωμένο σε οποιαδήποτε τυπική διαμόρφωση στην πλατφόρμα 1C:Enterprise 8 και παρέχει όλους τους απαραίτητους μηχανισμούς για γρήγορη και εύκολη εγκατάσταση και διαχείριση ενοποίησης. AXELOT: Το ESB Service Data Bus αλληλεπιδρά με τη διαμόρφωση στην πλατφόρμα 1C:Enterprise 8 μέσω υπηρεσιών SOAP και REST.

Τα στοιχεία διακομιστή "AXELOT: ESB Service Data Bus" αναπτύσσονται σε C++. Η διαχείριση και η διαμόρφωση του "AXELOT: ESB Service Data Bus" πραγματοποιείται στο περιβάλλον ανάπτυξης Eclipse και μπορεί να πραγματοποιηθεί σε συνδυασμό με την ανάπτυξη συστημάτων στην πλατφόρμα "1C: Enterprise 8" στο "1C: Enterprise Development Tools". Το "AXELOT: ESB Service Data Bus" είναι multi-platform και υποστηρίζει Λειτουργικά συστήματα MS Windows και Linux.

Το AXELOT Datareon ESB είναι μια εξ ολοκλήρου ρωσική ανάπτυξη και βρίσκεται στη διαδικασία ένταξης στο ενιαίο μητρώο ρωσικών προγραμμάτων για ηλεκτρονικούς υπολογιστές και βάσεις δεδομένων, τα οποία μπορούν να αγοραστούν από κρατικούς και δημοτικούς φορείς για την επίλυση ορισμένων προβλημάτων.

Κατά τη γνώμη μου, υπάρχουν δύο προσεγγίσεις για τη δημιουργία ενός διαύλου εταιρικής ολοκλήρωσης:

• "από ολοκληρωμένα συστήματα"·


• «από εφαρμοσμένες διαδικασίες».

Ας δούμε αυτές τις προσεγγίσεις με περισσότερες λεπτομέρειες.

Προσέγγιση "από ολοκληρωμένα συστήματα"

Σε αυτή την περίπτωση, ο δίαυλος ολοκλήρωσης θεωρείται ως ένα είδος μεταφοράς που εκτελεί δρομολόγηση και διαπραγμάτευση πρωτοκόλλων ανταλλαγής μηνυμάτων. Όλα τα μηνύματα περνούν από την αλυσίδα: κανάλι εισόδου του προσαρμογέα του συστήματος πηγής -> δρομολογητής -> κανάλι εξόδου του συστήματος δέκτη. Ο τύπος επικοινωνίας μεταξύ αυτών των στοιχείων και συγκεκριμένων τεχνολογιών εξαρτάται από το εάν τα μηνύματα που προέρχονται από ένα σύστημα πηγής μπορούν να έχουν πολλαπλά συστήματα προορισμού, από το αναμενόμενο φορτίο και προσέγγιση για να διασφαλιστεί η ακεραιότητα των δεδομένων (χρησιμοποιώντας μια κοινή συναλλαγή για όλα τα συστήματα πηγής ή τα δεδομένα μεταφέρονται σε κάθε σύστημα πηγής στη συναλλαγή του).

1. Εξάρτηση από συστήματα, όχι τύπους μηνυμάτων. Συνήθως, ο αριθμός των ολοκληρωμένων συστημάτων είναι αρκετές φορές μικρότερος από τον αριθμό των τύπων μηνυμάτων που μεταδίδονται.


2. Ευκολία σύνδεσης νέων συστημάτων δέκτη: για να συνδέσετε ένα νέο σύστημα δέκτη, αρκεί να εισαγάγετε τα δεδομένα στον πίνακα δρομολόγησης.


3. Ευκολία εφαρμογής του συστήματος παρακολούθησης της λύσης ολοκλήρωσης: τα δεδομένα για το σύστημα παρακολούθησης μπορούν να δημιουργηθούν σε ένα μέρος - στο δρομολογητή (ωστόσο, αυτό το σημείο μπορεί να γίνει αποδεκτό μόνο με επιφυλάξεις, καθώς υπάρχουν δεδομένα που δημιουργούνται μόνο στους προσαρμογείς ολοκληρωμένων συστημάτων).


4. Λύση ευκολίας υποστήριξης. Δεδομένου ότι όλα τα μηνύματα περνούν από έναν μόνο δρομολογητή, όλη η λογική της μετάδοσης μηνυμάτων και των εξαρτήσεων παρακολούθησης μεταξύ των μηνυμάτων μπορεί να εφαρμοστεί σε ένα μέρος - σε αυτόν τον δρομολογητή.


5. Κοινή χρήση του συστήματος μεταξύ προγραμματιστών. Δεδομένου ότι ο πυρήνας του συστήματος και όλοι οι προσαρμογείς είναι ανεξάρτητοι μεταξύ τους (η επικοινωνία παρέχεται μόνο μέσω αποκλειστικών και περιγραφόμενων διεπαφών), οι εργασίες για την ανάπτυξή τους μπορούν να κατανεμηθούν μεταξύ προγραμματιστών, γεγονός που επιτρέπει τον παραλληλισμό της διαδικασίας δημιουργίας και εφαρμογής μιας λύσης ολοκλήρωσης.

1. Η λύση ισχύει μόνο για την εφαρμογή ενοποιημένης λογικής μετάδοσης μηνυμάτων, π.χ. εάν υπάρχουν κανόνες για την παρακολούθηση εξαρτήσεων και μετασχηματισμού που είναι κοινοί για όλα ή τα περισσότερα μηνύματα. Αν ΔΙΑΦΟΡΕΤΙΚΟΙ ΤΥΠΟΙΤα μηνύματα έχουν εντελώς διαφορετική λογική παρακολούθησης εξάρτησης και διαχείρισης ανταλλαγής, είτε θα πρέπει να μετακινηθούν σε προσαρμογείς, γεγονός που εξαλείφει το πλεονέκτημα 4 ή θα είναι αδύνατο να εφαρμοστεί καθόλου.


2. Αυτό το σχήμα είναι κατάλληλο για την υλοποίηση μιας ασύγχρονης ανταλλαγής. Στην περίπτωση της σύγχρονης ή μικτής ανταλλαγής, η πολυπλοκότητα στην υλοποίηση αυτή η προσέγγισηαυξάνεται σημαντικά.


3. Μπορεί να προκληθεί υποβάθμιση της απόδοσης του διαλύματος. Για παράδειγμα, εάν ένα μήνυμα πρόκειται να μεταδοθεί σε καθένα από τα συστήματα δέκτη σε μια ξεχωριστή συναλλαγή, απαιτείται ο διαχωρισμός του συστήματος πηγής, του πυρήνα και των συστημάτων δέκτη με ουρές. Αυτές οι ουρές μπορούν να γίνουν το σημείο συμφόρησης του συστήματος.

Προσέγγιση "από εφαρμοσμένες διαδικασίες"

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

Αυτή η προσέγγιση έχει τα ακόλουθα πλεονεκτήματα:

1. Ευκαμψία. Αυτή η προσέγγιση σάς επιτρέπει να εφαρμόσετε τη δική σας, ξεχωριστή λογική ανταλλαγής για κάθε τύπο μηνύματος. Αυτή η λογική μπορεί να είναι αρκετά μη τετριμμένη.


2. Η πολυπλοκότητα της υλοποίησης τόσο της ασύγχρονης όσο και της σύγχρονης ανταλλαγής είναι περίπου η ίδια.


3. Ανεξαρτησία νημάτων, πιο συγκεκριμένα σε αυτή την περίπτωση είναι πιο σωστό να μιλάμε για διαδικασίες. Οι τεχνικές αποφάσεις που λαμβάνονται κατά την εφαρμογή μιας διαδικασίας ανταλλαγής δεν επηρεάζουν την πολυπλοκότητα της υλοποίησης μιας άλλης.

Αυτή η προσέγγιση έχει τα ακόλουθα μειονεκτήματα:

1. Εξάρτηση από τους τύπους μηνυμάτων. Συνήθως ο αριθμός των τύπων μηνυμάτων είναι πολλές φορές μεγαλύτερος από τον αριθμό των ολοκληρωμένων συστημάτων. Όταν συνδέετε ένα νέο σύστημα πηγής με το δίαυλο, είναι απαραίτητο να δρομολογήσετε μηνύματα κατά τύπους και να εφαρμόσετε μια ξεχωριστή διαδικασία ανταλλαγής για κάθε τύπο μηνύματος.


2. Εάν πρέπει να εφαρμοστεί η ίδια λογική ανταλλαγής για πολλούς τύπους μηνυμάτων, τότε είναι δυνατή η αντιγραφή των ρυθμίσεων κώδικα ή/και διαύλου.


3. Οι διαδικασίες μετάδοσης μηνυμάτων εξαρτώνται από τους προσαρμογείς συστήματος και μπορούν να εξαρτώνται η μία από την άλλη, καθώς και από τις διαδικασίες σέρβις. Η παρουσία τέτοιων εξαρτήσεων μειώνει τον βαθμό παραλληλισμού της διαδικασίας ανάπτυξης και εφαρμογής μιας λύσης ολοκλήρωσης. Οι προγραμματιστές ορισμένων στοιχείων εξαρτώνται από τα αποτελέσματα της εργασίας των προγραμματιστών άλλων στοιχείων της λύσης ενοποίησης.

Η επιλογή της προσέγγισης πραγματοποιείται σύμφωνα με τον ακόλουθο αλγόριθμο:

1. Λάβετε λίστα και περιγραφή ολοκληρωμένων συστημάτων και τύπων μηνυμάτων από αναλυτές.


2. Λάβετε από τους αναλυτές μια λίστα και περιγραφή των επιχειρηματικών διαδικασιών που περιλαμβάνουν συστήματα που απαιτούν ενοποίηση.


3. Εάν οι διαδικασίες είναι ασήμαντες και υπάρχουν πολύ λιγότερα συστήματα από τους τύπους μηνυμάτων, η ανταλλαγή είναι κατά κύριο λόγο ασύγχρονη και απαιτείται επίσης η μεταφορά ενός μηνύματος σε πολλά συστήματα, επιλέγουμε την πρώτη προσέγγιση. Αποφασίστε για την πολιτική διαχείρισης συναλλαγών.


4. Εάν οι διαδικασίες συνεπάγονται μια κατά κύριο λόγο σύγχρονη ανταλλαγή, ενώ οι διαδικασίες είναι πολύπλοκες, δηλ. το πέρασμα ενός μηνύματος εξαρτάται από τα αποτελέσματα της επεξεργασίας του σε συστήματα δεκτών, τότε επιλέγουμε τη δεύτερη προσέγγιση. Ένα άλλο επιχείρημα υπέρ αυτής της προσέγγισης είναι το γεγονός ότι ο αριθμός των τύπων μηνυμάτων είναι συγκρίσιμος με τον αριθμό των ολοκληρωμένων συστημάτων.

Πρέπει να γίνει ξεκάθαρα κατανοητό ότι αυτές οι μέθοδοι υλοποίησης δεν είναι δόγμα, δεν είναι απαραίτητο να επιλέξετε μόνο την πρώτη προσέγγιση ή μόνο τη δεύτερη. Μπορούν πάντα να συνδυαστούν, σύγχρονα εταιρικά ελαστικά σέρβις ( ESB) σας επιτρέπουν να το κάνετε.

Μου άρεσε η ανάρτηση -

Με αυτό το άρθρο, θα ήθελα να ανοίξω έναν κύκλο αφιερωμένο στο IBM WebSphere ESB (εφεξής ESB) στο πλαίσιο ανάπτυξης αυτού του προϊόντος. Και, πρώτα απ 'όλα, θα πρέπει να εξοικειωθείτε με τεχνολογίες αυτού του είδους.
Το Enterprise Service bus (enterprise Service bus) είναι ένα ενδιάμεσο λογισμικό που παρέχει ένα κεντρικό και ενοποιημένο μήνυμα προσανατολισμένο σε συμβάντα μεταξύ διαφόρων συστημάτων πληροφοριών με βάση τις αρχές μιας αρχιτεκτονικής προσανατολισμένης στις υπηρεσίες.
Φυσικά, είναι δυνατό χωρίς ειδικό λογισμικό (ίσως κάτι γενικό θα πρέπει ακόμα να αναπτυχθεί) να χτιστεί ένα εταιρικό σύστημα με βάση αυτή την προσέγγιση και αυτό που συμβαίνει ως αποτέλεσμα μπορεί να ονομαστεί λεωφορείο υπηρεσίας. Αλλά στο προϊόν της IBM δεν υπάρχει μόνο μια έτοιμη συσκευή για κεντρική ανταλλαγή μηνυμάτων και έλεγχο αυτής της διαδικασίας, αλλά και πλήρες σετευκαιρίες για την ανάπτυξη ευέλικτων εφαρμογών προσανατολισμένων στις υπηρεσίες ειδικά για το ESB. Συνοπτικά, μπορούν να επισημανθούν τα ακόλουθα χαρακτηριστικά και πλεονεκτήματα του IBM WebSphere ESB:

• Τάξη και ομοιομορφία των αρχιτεκτονικών σχέσεων
• Κεντρική Διοίκηση
• Διαμόρφωση εφαρμογής από την πλευρά του διακομιστή
• Εφαρμογή της τεχνολογίας Service Component Architecture (SCA) στο πνεύμα των αρχών της αρχιτεκτονικής με προσανατολισμό στις υπηρεσίες
• Πρωτόκολλο-ανεξαρτησία του αναπτυγμένου κώδικα προγράμματος
• Εκτεταμένες επιλογές διαμόρφωσης διαύλου και εφαρμογής

Ταυτόχρονα, η ESB παρέχει έλεγχο συναλλαγών, μετασχηματισμό δεδομένων, ασφάλεια και εγγυημένη παράδοση μηνυμάτων. Η πρόσβαση σε όλες τις υπηρεσίες μέσω ενός μόνο σημείου σάς επιτρέπει να διαμορφώνετε την επικοινωνία υπηρεσίας κεντρικά. Μπορείτε επίσης να διαχειριστείτε κεντρικά συμβάντα αποτυχίας για μαζικό χειρισμό σφαλμάτων.
Η κλασική τοπολογία συναρμολόγησης ESB είναι ένα σύμπλεγμα που παρέχει οριζόντια επεκτασιμότητα και ανοχή σφαλμάτων. Σύμφωνα με επίσημες συστάσεις, η αύξηση του αριθμού των μελών του συμπλέγματος αυξάνει την απόδοση πιο αποτελεσματικά από την αύξηση της χωρητικότητας του διακομιστή σε μια αυτόνομη τοπολογία. Επιπλέον, το σύμπλεγμα μπορεί να επανεκκινηθεί (ή μέρος του μπορεί να αποτύχει) χωρίς διακοπή της υπηρεσίας.
Το ESB χρησιμοποιείται συνήθως ως επίπεδο υπηρεσιών στο IBM BPM, αλλά μπορεί κάλλιστα να διαδραματίσει πρωταγωνιστικό ρόλο στη δημιουργία ενός μοντέλου αλληλεπίδρασης. εταιρικά συστήματαως ισχυρή συσκευή ενσωμάτωσης (δηλαδή το ESB ως πρόσθετο μέσω του IBM WebSphere Application Server).
Αυτό, στην πραγματικότητα, απαιτείται από το ESB, καθώς πρόκειται για ένα "σημείο συλλογής υπηρεσιών" - εάν χρειάζεστε μια υπηρεσία που θα συνεργάζεται με άλλες υπηρεσίες (πιθανώς εξωτερικές), τότε η ενοποίηση μεταξύ αυτών των υπηρεσιών γίνεται πιο λογικά στο ESB . Για εξωτερικές ή ετερογενείς υπηρεσίες, μπορείτε να κάνετε το "wrapper" υπηρεσία ESB. Ας δείξουμε λίγο την ευκολία χρήσης της "ενιαίας κατοικίας" για υπηρεσίες:

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


Αλλά είναι πολύ πιο εύκολο να έχετε μια υπηρεσία (ESB) που σας επιτρέπει να διεξάγετε όλη την αλληλεπίδραση μέσω της ίδιας. Με αυτήν την προσέγγιση, μέρος της αρχιτεκτονικής αλληλεπίδρασης σε οποιοδήποτε υποσύστημα είναι ήδη ξεκάθαρο - δεν υπάρχει χάος στις επικοινωνίες μεταξύ συστημάτων, διακομιστών και εφαρμογών: τα πάντα συνδέονται με το ESB και το ESB είναι συνδεδεμένο με τα πάντα.

Κεντρική Διοίκηση
Είναι πάντα πιο βολικό να διαμορφώνετε τα συστήματα κεντρικά - είτε πρόκειται για διαμόρφωση, προσαρμογή στη μετεγκατάσταση διακομιστή, ανοχή σφαλμάτων, εξισορρόπηση φορτίου, διαχείριση σφαλμάτων ή παρακολούθηση και ανάλυση.


Για παράδειγμα, όταν μετακινείτε έναν διακομιστή βάσης δεδομένων, δεν χρειάζεται να μπείτε στη διαμόρφωση όλων των υπαρχόντων διακομιστών εφαρμογών και στις ρυθμίσεις συγκεκριμένων εφαρμογών, αρκεί να έχετε μία μεταβλητή περιβάλλοντος στο ESB, η οποία καθορίζει τη βάση δεδομένων διεύθυνση και, στη συνέχεια, οι αλλαγές θα πρέπει να γίνουν σε ένα μόνο σημείο.
Ή εάν ένα από τα εξωτερικά συστήματα δεν ήταν διαθέσιμο για μεγάλο χρονικό διάστημα και δεν πρέπει να χαθεί ούτε ένα αίτημα προς αυτό, μπορείτε να χρησιμοποιήσετε την υπηρεσία για την επεξεργασία αποτυχημένων συμβάντων για να "πετάξετε" μηνύματα που δεν παραδόθηκαν όταν είναι βολικό.
Εάν χρειάζεται να ρυθμίσετε τον αριθμό των ταυτόχρονων αιτημάτων σε οποιοδήποτε σύστημα ή να παρακολουθήσετε αυτά τα αιτήματα, αναλύστε το φορτίο, αναζητήστε σημεία συμφόρησης - πρέπει να μεταβείτε στο κέντρο ελέγχου μηνυμάτων - στην κονσόλα διακομιστή ESB.

Διαμόρφωση από την πλευρά του διακομιστή
Η "ενιαία στέγαση" για υπηρεσίες, όσον αφορά τη διαμόρφωση, σας επιτρέπει να επιτύχετε αρκετούς χρήσιμους στόχους. Το πρώτο είναι η επαναχρησιμοποίηση της διαμόρφωσης (παρόμοια με την επαναχρησιμοποίηση κώδικα και μονάδας, η οποία είναι τόσο χρήσιμη στο SOA), επειδή διαφορετικές ενότητεςκαι οι εφαρμογές μπορούν να χρησιμοποιούν τις ίδιες παραμέτρους σύνδεσης βάσης δεδομένων, πόρους, παραμέτρους ελέγχου ταυτότητας, μεταβλητές περιβάλλοντος και ούτω καθεξής.


Δεύτερον, κατά τη ρύθμιση παραμέτρων από την πλευρά του διακομιστή, είναι το περιβάλλον εφαρμογής που μπορεί να το επηρεάσει σε μεγάλο βαθμό, το οποίο σας επιτρέπει να μεταφέρετε εφαρμογές μεταξύ διαφορετικών κυκλωμάτων (δοκιμή και παραγωγή), να συντονίζετε και ακόμη και να διορθώνετε σφάλματα χωρίς να κάνετε αλλαγές στην εφαρμογή.

Εάν χρησιμοποιήσετε όλα αυτά τα πλεονεκτήματα, οι εφαρμογές αποκτούν την ικανότητα ενός πραγματικού χαμαιλέοντα - είναι τόσο ευέλικτες που γίνονται μέρος του περιβάλλοντος στο οποίο εργάζονται και ταυτόχρονα φέρνουν τη σημαντική λειτουργικότητά τους.

Ωστόσο, η ευελιξία των εφαρμογών στο πλαίσιο του IBM WebSphere ESB δεν περιορίζεται στο περιβάλλον στο οποίο εκτελούνται. Οι δυνατότητες ανάπτυξης συμβάλλουν τεράστια σε αυτό. Δεδομένου ότι τα συστήματα όχι μόνο πρέπει να έχουν ένα μέρος για να λειτουργούν, αλλά πρέπει επίσης να αναπτυχθούν και να οριστικοποιηθούν, δεν πρέπει να χάσετε αυτά τα ενδιαφέροντα σημεία:

SCA
Αυτή η αρχιτεκτονική βασίζεται στην αρχή ότι ένα στοιχείο εκθέτει τη λειτουργικότητά του ως υπηρεσία διαθέσιμη σε άλλα στοιχεία. Μέσα σε μία ενότητα, τα στοιχεία είναι μπλοκ προγράμματος (κώδικας java) που υλοποιούν πλήρως κάποια λειτουργικότητα που περιγράφεται από την αντίστοιχη διεπαφή. Η λογική εκτέλεσης των στοιχείων υλοποιείται συνδέοντάς τα σε μια δομή με διεπαφές και αναφορές (Partner Reference).

Είναι πολύ βολικό να αναπτύξετε, να ελέγξετε, να αναπτύξετε, να αλλάξετε και να διατηρήσετε μια τέτοια δομή ενότητας. Η ατομικότητα της λειτουργικότητας που εφαρμόζεται στα εξαρτήματα σάς επιτρέπει να χειρίζεστε τα στοιχεία στο σύνολό τους χωρίς να πηγαίνετε στο επίπεδο κώδικα. Από την άλλη πλευρά, είναι λογικά απαραίτητο λόγω της εκτέλεσης εφαρμογών στοιχείων σε ένα συναλλακτικό πλαίσιο.
Κάθε στοιχείο έχει μια διεπαφή(ες) που παρέχει μια υλοποίηση. Έτσι, συνδέοντας τα εξαρτήματα μεταξύ τους, δεν χρειάζεται να τα γνωρίζουμε εσωτερικά χαρακτηριστικά– αρκεί να εφαρμόσουν τις απαραίτητες διεπαφές.
Μέσω αυτής της αρχιτεκτονικής, μπορείτε επίσης να επιλύσετε όλες τις εργασίες που απαιτούν παράλληλη εργασία, χωρίς "χειροκίνητο" έλεγχο ροής (για παράδειγμα, μπορείτε να πραγματοποιήσετε ασύγχρονες κλήσεις σε πολλά στοιχεία με καθυστέρηση απόκρισης).
Στοιχεία που δεν είναι java, όπως οι τύποι Εξαγωγή και Εισαγωγή, σας επιτρέπουν να παρέχετε υπηρεσίες για εξωτερική χρήσηή χρησιμοποιήστε εξωτερικές υπηρεσίες αναλόγως· Το στοιχείο Ροή διαμεσολάβησης παρέχει πρόσβαση χαμηλού επιπέδου σε μηνύματα που ανταλλάσσονται μεταξύ άλλων στοιχείων και επιτρέπει διάφορους μετασχηματισμούς κατά την εργασία με ετερογενείς διεπαφές.
Εκτός από τις διεπαφές, το πλαίσιο επιχειρηματικού αντικειμένου της IBM παρέχει πολύ χρήσιμες λειτουργίες. Τα επιχειρηματικά αντικείμενα (BO), που αντιπροσωπεύονται από σχήματα xsd, χρησιμοποιούνται ως αντικείμενα για μεταφορά δεδομένων σε διεπαφές, τόσο μεταξύ στοιχείων όσο και για επικοινωνία μεταξύ λειτουργικών μονάδων. Ενσωματώνονται απευθείας, για παράδειγμα, στο σχήμα wsdl για την περιγραφή των υπηρεσιών Ιστού. Δηλαδή, για παράδειγμα, εάν η ενότητα "Α" παρέχει τη λειτουργικότητά της ως υπηρεσία web, για να τη χρησιμοποιήσετε, αρκεί η ενότητα "Β" να συνδέσει τη διεπαφή και τα έτοιμα BO και θα μπορεί να λειτουργεί πλήρως με μια τέτοια υπηρεσία χωρίς τη δημιουργία πρόσθετων αντικειμένων java για μεταφορά δεδομένων. Το BO είναι επίσης βολικό στη χρήση κατά την ανταλλαγή δεδομένων με τη βάση δεδομένων, εάν αυτά τα δεδομένα χρησιμοποιούνται από άλλα στοιχεία (αυτό, φυσικά, έρχεται σε αντίθεση με το πρότυπο DAO, αλλά εξαλείφει τα περιττά αντικείμενα java και τις λειτουργίες επανεγγραφής δεδομένων εμπρός και πίσω).

Πρωτόκολλο-ανεξαρτησία του κώδικα προγράμματος
Όπως μπορείτε να δείτε, η ανεξαρτησία του κώδικα από πρωτόκολλο επιτυγχάνεται χρησιμοποιώντας τα στοιχεία Εξαγωγή και Εισαγωγή. Εφόσον η επικοινωνία με αυτά τα στοιχεία γίνεται μέσω διεπαφών και παραπομπών, κώδικα προγραμματισμούεντελώς ανεξάρτητο από το πρωτόκολλο που χρησιμοποιείται για την αλληλεπίδραση. Η ίδια λειτουργικότητα μπορεί εύκολα να γίνει διαθέσιμη σε οποιοδήποτε αριθμό υποστηριζόμενων πρωτοκόλλων και σε οποιοδήποτε τις σωστές διεπαφές. Το παρακάτω σχήμα δείχνει πώς μπορείτε να προσθέσετε μια εξαγωγή με δέσμευση SCA σε ένα φασόλι που ήδη εκθέτει τη διεπαφή του ως HTTP, JMS και υπηρεσία Web.


Τα οφέλη είναι προφανή - ευελιξία, ευελιξία, επαναχρησιμοποίηση κώδικα, ταχύτητα ανάπτυξης και τροποποίησης.
Παρεμπιπτόντως, το SCA binding χρησιμοποιεί ένα ειδικό πρωτόκολλο και προορίζεται για επικοινωνία μεταξύ μονάδων στον ίδιο διακομιστή/σύμπλεγμα. Η επικοινωνία μέσω αυτής της δέσμευσης είναι λιγότερο απαιτητική για πόρους και ταχύτερη από άλλα πρωτόκολλα.

Διαμόρφωση
Η διαμόρφωση του διακομιστή και της εφαρμογής γίνεται μέσω της κονσόλας IBM του διακομιστή.
Το ESB, όπως και το IBM WebSphere γενικά, έχει αρκετά συγκεκριμένα χαρακτηριστικά και τεχνουργήματα. Για παράδειγμα, όταν χρησιμοποιείτε τις ίδιες εισαγωγές και εξαγωγές, μπορείτε να διαμορφώσετε τα τελικά σημεία των αντίστοιχων υπηρεσιών εν κινήσει. Για κλήσεις υπηρεσίας, μπορείτε να διαμορφώσετε σύνολα πολιτικών με διάφορους κανόνες (για παράδειγμα, μπορείτε να εγκαταστήσετε υποστήριξη για τον μηχανισμό WS-AT, ο οποίος σας επιτρέπει να καλείτε μια υπηρεσία web στην ίδια συναλλαγή στην οποία εργάζεται ο πελάτης, αλλά η συναλλακτικότητα είναι ήδη θέμα για ένα πλήρες άρθρο), ορίστε παραμέτρους ελέγχου ταυτότητας, συνδέστε πιστοποιητικά και πολλά άλλα.
Μέσω της διαμόρφωσης, μπορείτε να ρυθμίσετε ορισμένους μηχανισμούς για αυτόματη απόκριση σε εξαιρετικές καταστάσεις (για παράδειγμα, αυτόματη επανάληψη της εκτέλεσης στοιχείου σε περίπτωση σφαλμάτων). Μπορείτε να ρυθμίσετε την ανίχνευση στοιχείων εν κινήσει ή να αλλάξετε τα επίπεδα καταγραφής. Διατίθεται επίσης μια υπηρεσία διαχείρισης συμβάντων αποτυχίας, η οποία μπορεί να χρησιμοποιηθεί σκόπιμα για μαζικό χειρισμό σφαλμάτων.
Και, φυσικά, μπορείτε να διαμορφώσετε πολλά άλλα πράγματα σύμφωνα με την προδιαγραφή Java2EE, η οποία, μερικές φορές αρκετά αυστηρά, εφαρμόζεται στον IBM Application Server.

Όλα τα παραπάνω επιβεβαιώνουν το ESB ως μια βολική, ισχυρή και ευέλικτη συσκευή ενσωμάτωσης, αν και όχι πάντα εύκολη στην εκμάθηση. Στο μέλλον, θα πρέπει απλώς να μάθετε πώς να το χρησιμοποιείτε.

Οι παρακάτω εικόνες χρησιμοποιήθηκαν στο άρθρο:

Είμαι προσωπικά εξοικειωμένος με το SOA εδώ και 10 χρόνια, κατά τη διάρκεια αυτής της περιόδου έχω αναπτύξει μια σαφή συσχετιστική αλυσίδα: η βάση του SOA είναι ο δίαυλος δεδομένων, λοιπόν, από το δίαυλο δεδομένων, τότε μιλάμε για έργα ολοκλήρωσης.

Δεν θα ξεσηκώσω την ιστορία, όλοι θυμόμαστε πώς αναπτύχθηκε η ενοποίηση στην εποχή της: μια μακρά και επίπονη διαδρομή από την έννοια από σημείο σε σημείο σε ένα δίαυλο με ένα αποκλειστικό μοντέλο δεδομένων στο επίπεδο ενοποίησης. Σήμερα μιλάμε ήδη για το προϊόν ολοκλήρωσης Neoflex Integra, το οποίο έχει ένα ανάλογο ρωσική αγοράΔεν υπάρχει ακόμη τραπεζικός αυτοματισμός, ότι το αρχικό στάδιο των αναλυτικών στοιχείων μπορεί να μειωθεί σημαντικά και ταυτόχρονα να αξιολογηθεί άμεσα το αποτέλεσμα ενός μελλοντικού έργου ολοκλήρωσης.

Η Neoflex Integra εμφανίστηκε μετά το 450ο ή και το 455ο έργο ολοκλήρωσης που πραγματοποιήθηκε στην τράπεζα. Είναι δύσκολο να προσδιορίσεις ακριβώς. Προσπαθήσαμε όμως να υπολογίσουμε τις ανθρωποημέρες που αφιερώθηκαν στην πρακτική της ένταξης από τους υπαλλήλους μας και αποδείχτηκε ότι ήταν περίπου 137 χρόνια. Η ενσωμάτωση ήταν πάντα ένας από τους κύριους τομείς της δουλειάς της Neoflex, επομένως δεν πρέπει να εκπλαγείτε με μια τέτοια φιγούρα. Σε αυτό το διάστημα καταφέραμε να καταλάβουμε δύο πράγματα. Πρώτον, τα τοπία στα δανειστικά ιδρύματα είναι ταξινομήσιμα. Δεύτερον, υπάρχουν πολλά κοινά μεταξύ των έργων ολοκλήρωσης, τουλάχιστον στο στάδιο της ανάλυσης. Έχουμε ξεχωρίσει τη βάση με τη μορφή ενός γενικού κανονικού μοντέλου που περιέχει αντικείμενα εφαρμογής και σχέσεις μεταξύ τους, συνδυάζοντας τις ατομικές υπηρεσίες σε επιχειρηματικές διαδικασίες στους τομείς δραστηριότητας ενός χρηματοπιστωτικού οργανισμού. Φαίνεται φανταστικό, αλλά τώρα μπορούμε να έρθουμε στην τράπεζα με μια σειρά από έτοιμες «λεπτομέρειες» και να τις χρησιμοποιήσουμε για να διαμορφώσουμε ένα μελλοντικό μοντέλο ολοκλήρωσης. Το Neoflex Integra είναι ένα νέο προϊόν, το ανακοινώσαμε στο τεύχος Μαρτίου του The Retail Finance. Αλλά σήμερα μπορούμε ήδη να πούμε ότι θα επιτρέψει τη μείωση της διάρκειας του έργου ολοκλήρωσης κατά περίπου ένα τέταρτο, επιπλέον, η τράπεζα δεν αγοράζει πλέον ένα "γουρούνι στο σακί", όπως ήταν πριν, πληρώνει για πολύ βέβαιο αποτέλεσμα. Ωστόσο, ας επιστρέψουμε στο SOA, και για όσους ενδιαφέρονται για το θέμα ενός προϊόντος ενσωμάτωσης, σας προσκαλώ να επισκεφθείτε το διαδικτυακό σεμινάριο "Νέο προϊόν Neoflex Integra: η πεμπτουσία της εμπειρίας έργου" στις 20 Νοεμβρίου.

Λοιπόν, τι θα συμβεί στη συνέχεια, πώς θα αναπτυχθεί το SOA, θα παραμείνει ο δίαυλος δεδομένων και θα πάρει την ίδια τιμητική θέση όπως τώρα στο τοπίο της πίστωσης και, αν κοιτάξετε ευρύτερα, τότε όχι μόνο πιστωτικός οργανισμός; Θα ξεκινήσω από μακριά, για το SOA γενικά, για το ποια είναι η τύχη αυτής της έννοιας στον τραπεζικό κλάδο. Στην πραγματικότητα, η σωστή αρχιτεκτονική πληροφορικής για μια τράπεζα είναι αυτή που μπορεί να καλύψει τις επιχειρηματικές της ανάγκες. Όσο μεγαλύτερη είναι η τράπεζα, τόσο υψηλότερα είναι τα αιτήματα. Στη Ρωσία, με τις πολυκλαδικές, γεωγραφικά κατανεμημένες δομές της, υπάρχουν αρκετές μεγάλες τράπεζες, αλλά ακόμη και αυτές δεν μπορούν πάντα να αντέξουν οικονομικά ένα τοπίο υψηλής ποιότητας SOA, και όχι μόνο επειδή είναι πολύ ακριβό, αλλά και επειδή είναι τεράστιος κίνδυνος. Τα έργα SOA δεν τελειώνουν πάντα καλά. Με το προϊόν μας, σχεδιάζουμε να μειώσουμε τους κινδύνους, και ταυτόχρονα το όριο για την είσοδο στο SOA.

Μην νομίζετε ότι το τοπίο SOA είναι μια επιχείρηση σωλήνων. Τα έργα Neoflex δείχνουν ότι δεν υπάρχουν μη ολοκληρωμένα συστήματα. Οι τράπεζες συνήθως αρχίζουν να δημιουργούν ένα νέο τοπίο σιγά σιγά, ξεκινώντας από τους τομείς που είναι πιο σημαντικοί για αυτές, αλλά πρόσφατα συναντήσαμε μια κλίμακα που δεν έχουμε ξαναδεί. Συνέβη σε ένα έργο στην τράπεζα VTB24. Η εταιρεία εργάστηκε εκεί για να δημιουργήσει ένα Universal Layer Banking Services που βασίζεται στη σουίτα Oracle SOA. Η λύση περιελάμβανε περισσότερες από 600 υπηρεσίες που διασφαλίζουν τη συνεργασία της τράπεζας με όλους τους πελάτες μέσω όλων των καναλιών επικοινωνίας. Μια τόσο μεγάλη και πολύπλοκη απόφαση, σύμφωνα με συναδέλφους της Oracle, δεν θα θυμούνται στη Ρωσία. Και αν πέτυχε, τότε άλλα έργα είναι καθαρά τεχνικά εφικτά.

Η ανάγκη να σχηματιστεί ένα ενιαίο λογικό επίπεδο και να βελτιστοποιηθεί ο χώρος πληροφορικής αντιμετωπίζεται περισσότερο από τις τράπεζες που διαχειρίζονται μεγάλο αριθμό έργων λιανικής. Η ταχύτητα της εξυπηρέτησης πελατών είναι κρίσιμη εδώ και οι τεχνικές που χρησιμοποιούνται στην πρακτική SOA μπορούν να την αυξήσουν σημαντικά λόγω της ταχύτερης ροής δεδομένων. Ως εκ τούτου, κορυφαίες τράπεζες όπως η VTB24, η Probusinessbank ( Ομάδα ζωής), με την οποία συνεργαζόμαστε επίσης, υιοθέτησε μακροπρόθεσμα προγράμματα μετάβασης SOA πριν από λίγο καιρό. Το αν οι μικρότεροι οργανισμοί θα ακολουθήσουν το παράδειγμά τους είναι δύσκολο να πούμε: η κρίση είναι τελικά. Αλλά οι καθαρά πρακτικές σκέψεις είναι οι εξής. Αν προσπαθήσουμε να χαράξουμε ένα όριο υπό όρους μεταξύ αυτών που χρειάζονται SOA και εκείνων που μπορούν να τα βγάλουν πέρα ​​με απλούστερες λύσεις, τότε αυτό το όριο, πριν αρχίσει η στασιμότητα στην αγορά, πέρασε περίπου από τις 400 κορυφαίες τράπεζες.

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

Τι να κάνετε με το IBM WebSphere ESB;

Αναμφίβολα, το IBM WebSphere ESB είναι ο ηγέτης της αγοράς μεταξύ των λεωφορείων ενοποίησης τόσο ως προς τον αριθμό των έργων όσο και ως προς τον αριθμό των υλοποιήσεων. Από τα 10 έργα ενοποίησης, τα 8 γίνονται στο IBM WebSphere ESB. Και μόνο τα τελευταία 2 χρόνια η κατάσταση άρχισε να αλλάζει λίγο και η κίνηση άλλων μεγάλων παγκόσμιων πωλητών άρχισε να εμφανίζεται στην αγορά. Δεν θα ήθελα να τα συγκρίνω στο πλαίσιο αυτού του άρθρου, καθώς χωρίς αυτό υπάρχει επαρκής αριθμός συγκρίσεων και αναλυτικών μελετών για αυτό το θέμα. Το άρθρο μου απευθύνεται σε αυτούς που κάποτε έκαναν ένα βήμα προς το SOA και το έκαναν μαζί με το IBM WebSphere ESB. Και έπρεπε να ανησυχούν σοβαρά: ξαφνικά, σαν χιόνι στα κεφάλια τους, η περσινή είδηση ​​ότι η IBM άλλαξε τη σειρά προϊόντων του λογισμικού ενσωμάτωσης από το 2014 και το IBM Web Sphere ESB δεν θα αναπτύσσεται πλέον, και υποστήριξη για αυτό Το συγκρότημα μόλις πρόσφατα επεκτάθηκε μέχρι τον Απρίλιο του 2018. Προηγουμένως, είχε προγραμματιστεί να ολοκληρωθεί το 2014.

Από αυτή την άποψη, όλο και περισσότεροι πελάτες μας που χρησιμοποίησαν αυτήν την πλατφόρμα ενσωμάτωσης άρχισαν να κάνουν ερωτήσεις σχετικά με το τι τους περιμένει.

Θαύματα δεν γίνονται, και δεν είμαι μάγος, αλλά θέλω να προσφέρω δύο τρόπους:

1. Αρχίστε να σκέφτεστε να χρησιμοποιήσετε μια άλλη πλατφόρμα στην οποία στοιχηματίζει η IBM στο μέλλον - Integration Bus (πρώην Message Broker).

Έχει προφανή πλεονεκτήματα έναντι του IBM WebSphere ESB: απόδοση και αξιοπιστία. Υπάρχουν επίσης αρκετά έργα και υλοποιήσεις με αυτήν την πλατφόρμα και κάποιος από την αρχή την επέλεξε ως λεωφορείο ολοκλήρωσης.

Το κύριο τεχνολογικό του χαρακτηριστικό είναι η εσωτερική χρήση του Message Queuing (MQ) ως μέσο μεταφοράς, που μας παρέχει εγγυημένη παράδοση μηνυμάτων και, κατά συνέπεια, αξιοπιστία.

2. Ήδη τώρα, όταν αναπτύσσετε μια λύση ενοποίησης στο IBM WebSphere ESB, προσπαθήστε να διαχωρίσετε τα επίπεδα υλοποίησης για να δημιουργήσετε νέο κωδικόόχι στο IBM WebSphere ESB, αλλά σε άλλα στοιχεία, η χρήση των οποίων στη λύση ενσωμάτωσης αντιστοιχεί στη στρατηγική περαιτέρω εξέλιξης. Δεν υπάρχουν πολλά κατάλληλα προϊόντα από την IBM, μόνο 2-3. Ένα από αυτά, κατά τη γνώμη μου, το πιο πολλά υποσχόμενο είναι το IBM WebSphere Data Power, ένα σύστημα υλικού και λογισμικού για την επίλυση εργασιών ενοποίησης που παρέχει υψηλή απόδοση και πιστοποιημένη ασφάλεια. Τα πλεονεκτήματα αυτού του προϊόντος είναι η υψηλότερη απόδοση στην κατηγορία του και η ικανότητα επίλυσης ενός ευρέος φάσματος εργασιών ασφαλείας, τόσο εξωτερικών όσο και εσωτερικών.

Μέχρι σήμερα, έχουμε περισσότερα από εντυπωσιακά αποτελέσματα από ένα από τα πιλοτικά έργα με το IBM Data Power, που ολοκληρώθηκε στην Renaissance Credit Bank: 40 αιτήματα ανά δευτερόλεπτο υποβάλλονται σε επεξεργασία με 5.000 ταυτόχρονες συνδέσεις και ο χρόνος επεξεργασίας για 1 αίτημα είναι μικρότερος από 1 ms. Αξίζει να σημειωθεί ότι το φορτίο της CPU κατά τη διάρκεια των δοκιμών ήταν στο επίπεδο του 5%!

Η χρήση του IBM Data Power θα βοηθήσει στον διαχωρισμό των επιπέδων της λύσης ενσωμάτωσης μεταξύ του IBM WebSphere ESB και του IBM DataPower, επομένως κατά την αντικατάσταση του IBM WebSphere ESB με έναν νέο δίαυλο ενοποίησης, για παράδειγμα, με το IBM Integration Bus, δεν χρειάζεται να επαναλάβετε το τμήμα για IBM DataPower.

Αυτή η προσέγγιση υβριδικού διαύλου μπορεί επίσης να εφαρμοστεί με βάση προϊόντα από άλλους προμηθευτές, π.χ. όχι μόνο η IBM. Επειδή η ανάπτυξη προϊόντων πολλών πωλητών συχνά πηγαίνει προς την ίδια κατεύθυνση, αλλά αυτό είναι ένα θέμα για ξεχωριστή συζήτηση.

Πώς πρέπει να είναι ένας δίαυλος δεδομένων ενοποίησης στο εγγύς μέλλον;

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

Στις μέρες μας είναι πολύ δύσκολο να καλύψει όλες τις απαιτήσεις μιας επιχείρησης με οποιοδήποτε προϊόν. Η παλιά, δοκιμασμένη και αληθινή αρχή "καλύτερης φυλής" είναι επομένως απόλυτα κατάλληλη για ελαστικά ενσωμάτωσης.

Πάρτε πολλά προϊόντα, συνδυάστε τα με μια κοινή εργασία, διαχωρίστε τα εξαρτήματα μεταξύ τους, «φυτέψτε» τα σε ένα κοινό μοντέλο δεδομένων ολοκλήρωσης και όχι μόνο θα έχετε μια πολυλειτουργική λύση, αλλά και θα προστατευτείτε από τον «εθισμό στα προϊόντα».

Βρήκαμε λοιπόν δύο απλές λύσεις, καθένα από τα οποία έχει τα δικά του πλεονεκτήματα:

· Το IBM WebSphere ESB σε συνδυασμό με το IBM Integration Bus χρησιμοποιείται για τη δημιουργία πλατφορμών SOA, την ενοποίηση πολύπλοκων εφαρμογών και περιβαλλόντων πληροφορικής.

Υψηλή απόδοση προϊόν της IBMΤο DataPower, που χαρακτηρίζεται από ευκολία στη διαμόρφωση, χρησιμοποιείται για την επεξεργασία απλών αιτημάτων και για την παροχή πολυλειτουργικής ασφάλειας.

Αναμφίβολα, τα υβριδικά λεωφορεία είναι το μέλλον, εκτός και αν έχουμε ένα δίαυλο δεδομένων στο cloud, ακόμα κι αν φαίνεται απίθανο τώρα. Θα επιστρέψουμε σε αυτό το θέμα σε ένα ή δύο χρόνια. Συμφωνείς?

Το μπλοκ των συστημάτων BPM δεν εξετάστηκε σκοπίμως εδώ, γιατί. αυτό είναι ένα ξεχωριστό εκτενές θέμα.