) เดิมเรียกว่า Axelot Datareon ESB มีวัตถุประสงค์เพื่อสร้างภูมิทัศน์ข้อมูลแบบกระจายขององค์กร ผลิตภัณฑ์ซอฟต์แวร์ช่วยให้มั่นใจถึงการโต้ตอบของแอปพลิเคชันที่ผสานรวมทั้งหมดในศูนย์เดียว โดยผสมผสานแหล่งข้อมูลที่มีอยู่และให้การแลกเปลี่ยนข้อมูลแบบรวมศูนย์ระหว่างระบบข้อมูลที่แตกต่างกัน
บัสบริการข้อมูลองค์กร Datareon ESB เป็นวิธีการรับประกันความเสถียรและความสมบูรณ์ของการแลกเปลี่ยนข้อมูล เพิ่มประสิทธิภาพโดยรวมของระบบข้อมูล และลดต้นทุนค่าแรงในการบริหารจัดการ
ผลิตภัณฑ์ซอฟต์แวร์ Datareon ESB ได้รับการรวมอย่างเป็นทางการในการลงทะเบียนแบบรวมของโปรแกรมรัสเซียสำหรับคอมพิวเตอร์อิเล็กทรอนิกส์และฐานข้อมูล ซึ่งสถาบันของรัฐและเทศบาลสามารถซื้อได้
ฟังก์ชั่นการทำงาน
- รองรับมาตรฐานและสถานการณ์บูรณาการที่หลากหลาย
- จัดการภูมิทัศน์การบูรณาการของคุณจากส่วนกลางด้วยระบบนิเวศ Eclipse
- การแปลงข้อมูล (อัลกอริธึมการแปลงข้อมูลหลายขั้นตอนพร้อมการควบคุมเงื่อนไขต่างๆ)
- ถ่ายโอนข้อมูลทุกขนาด (มาตราส่วนแนวตั้งและแนวนอน)
- บูรณาการอย่างง่ายดายกับผลิตภัณฑ์บนแพลตฟอร์ม 1C:Enterprise 8
- รับประกันการถ่ายโอนข้อมูลที่ปลอดภัย
- การวินิจฉัยและการตรวจสอบสถานะของเครือข่ายการส่งข้อมูลทั้งหมด
ปัญหาที่ต้องแก้ไข
- การถ่ายโอนข้อมูลระหว่างระบบข้อมูลต่างๆ (แบบมีเส้นทางหรือจุดต่อจุด)
- การก่อตัวของพื้นที่ข้อมูลเดียวในสภาพแวดล้อมที่ต่างกัน
- การสร้างระบบแบบกระจายตามโมเดลเหตุการณ์ในตัวเลือกต่อไปนี้:
- การสร้างแอปพลิเคชันด้วยกระบวนการทางธุรกิจแบบ end-to-end ตามโมเดลเหตุการณ์
- การสร้างระบบที่มีการซิงโครไนซ์แอพพลิเคชั่นทางธุรกิจในระบบสารสนเทศต่างๆ
- การได้รับสถาปัตยกรรมการจัดการระดับองค์กร/การถือครองที่ปรับขนาดได้
- การปรับใช้ระบบการแลกเปลี่ยนข้อมูลในระดับการขนส่งและในระดับตรรกะทางธุรกิจ
- การมอบหมายงานการสร้างกระแสข้อมูลให้กับแผนกวิเคราะห์
- ลดความซับซ้อนในการออกแบบการรวมระบบโดยรวมและลดข้อกำหนดปริมาณงานของช่องสัญญาณ
- เพิ่มความเสถียรโดยรวมของเลเยอร์การขนส่งข้อมูล
- ลดต้นทุนการทำธุรกรรมเมื่อแลกเปลี่ยนข้อมูลระหว่างแผนกต่างๆ
2017
Axelot Datareon ESB 2.1.0.0
โซลูชัน AXELOT Datareon ESB ถูกรวมอยู่ในรายการความสามารถด้านการพัฒนาแอปพลิเคชันระดับ Gold ซึ่งเป็นข้อเท็จจริงที่ยืนยันถึงคุณภาพของผลิตภัณฑ์และความเข้ากันได้กับผลิตภัณฑ์ของ Microsoft
AXELOT Datareon ESB มอบคุณประโยชน์หลักหลายประการให้กับธุรกิจ:
- ความเป็นไปได้ของการรวมกลุ่ม
- ความน่าเชื่อถือและการนำทรัพยากรกลับมาใช้ซ้ำได้
- การได้รับสถาปัตยกรรมการจัดการระดับองค์กร/การถือครองที่ปรับขนาดได้
- การมอบหมายงานการสร้างกระแสข้อมูลให้กับแผนกวิเคราะห์
- ลดความซับซ้อนโดยรวมของโครงการบูรณาการและลดข้อกำหนดสำหรับปริมาณงานของช่องทาง
- เพิ่มเสถียรภาพโดยรวมของชั้นการถ่ายโอนข้อมูลการขนส่ง
- ลดต้นทุนการทำธุรกรรมเมื่อแลกเปลี่ยนข้อมูลระหว่างแผนกต่างๆ
- ลดต้นทุนโดยรวมในการบำรุงรักษาและบำรุงรักษาระบบสารสนเทศ
คุณสมบัติหลักของระบบ:
- ตัวเชื่อมต่อจำนวนมากไปยังระบบต่างๆ: 1C:Enterprise 8, บริการ SOAP, บริการ REST, MS SQL, IBM DB2, Oracle DB, PostgreSQL, SharePoint, OData, TCP, Siemens TeamCenter และอื่น ๆ
- กลไกปลั๊กอินสำหรับการพัฒนาตัวเชื่อมต่อด้วยตนเอง
- รองรับภาษาการเขียนโปรแกรมและเทคโนโลยีต่างๆ เมื่อพัฒนาสถานการณ์การโต้ตอบ: 1C:Enterprise 8, JavaScript, T-SQL;
- การตั้งค่าสถานการณ์การแปลงข้อมูลแบบหลายขั้นตอนโดยใช้กลไกการแมปภาพและการแปลง XSLT แบบกำหนดเอง
- ทำงานกับรูปแบบข้อมูลต่าง ๆ (XML, JSON, XLS, DBF, CSV, Base64 และอื่น ๆ )
- การกำหนดเส้นทางแพ็กเก็ตข้อมูลแบบคงที่และไดนามิก
- ความเร็วสูงของการโต้ตอบและความทนทานต่อข้อผิดพลาด: ข้อกำหนดที่ลดลงสำหรับแบนด์วิธเครือข่าย, การทำโหลดบาลานซ์, การแยกโดเมนข้อมูล, ความสามารถในการตรวจสอบสถานะของโหนดการรวม
- รองรับโมเดลเหตุการณ์ การโทรแบบซิงโครนัสและอะซิงโครนัส การส่งมอบที่รับประกัน
- การเปลี่ยนแปลงสถานการณ์บูรณาการของระบบสมาชิก (การขนถ่าย/การโหลด การเปลี่ยนแปลง และกลไกการกำหนดเส้นทาง) ในโหมด "ร้อน" โดยไม่จำเป็นต้องหยุด (รวมถึงการกำหนดค่าบนแพลตฟอร์ม 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" เป็นหลายแพลตฟอร์มและรองรับระบบปฏิบัติการ MS Windows และ Linux
AXELOT Datareon ESB เป็นการพัฒนาของรัสเซียโดยสมบูรณ์ และกำลังอยู่ในระหว่างการรวมอยู่ในทะเบียนรวมของโปรแกรมรัสเซียสำหรับคอมพิวเตอร์อิเล็กทรอนิกส์และฐานข้อมูล ซึ่งสถาบันของรัฐและเทศบาลสามารถซื้อได้เพื่อแก้ไขปัญหาบางอย่าง
ในมอสโกตั้งแต่ปี 1958 มีถนน Stroiteley ที่ 3 แต่ในปี 1963 ได้เปลี่ยนชื่อ - ปัจจุบันเป็นถนน Maria Ulyanova และอาคาร 25 บนถนนสายนี้เป็นอาคารห้าชั้นของครุสชอฟ ในเลนินกราด (เซนต์ปีเตอร์สเบิร์ก) ถนนสายที่ 3 ของช่างก่อสร้างไม่เคยมีอยู่จริง...
ฉันกำลังพูดถึงการรวมแอปพลิเคชันอีกครั้ง วันนี้ฉันอ่านมาตรฐานภายในประเทศสำหรับโฟลว์เอกสารระหว่างแผนก GOST R 53898-2010 และดูเหมือนว่ามาตรฐานจะ "ถูกต้อง" ที่เขียนด้วย XML และมีฟิลด์ที่มีประโยชน์ทุกประเภทใน 53 หน้าและรายละเอียดทั้งหมด ฉันจำได้ว่าในช่วงปลายศตวรรษที่ผ่านมา ฉันสนับสนุนอย่างยิ่งให้มีการเกิดขึ้นของมาตรฐานสำหรับข้อความอิเล็กทรอนิกส์บนหน้านิตยสารคอมพิวเตอร์ในบทความ The Internet Factor ในการพัฒนาระบบลูกค้า-ธนาคาร ในตอนท้ายของศตวรรษที่ผ่านมา ทุกอย่างดูเป็นแง่ดีมากกว่าตอนเริ่มต้นของเรื่องนี้ ดอทคอมยังไม่พัง ท้องฟ้าสูงขึ้น หญ้าก็เขียวขึ้น เว็บไซต์โซเชียลน่าเชื่อถือ และฟิลดิงยังไม่ได้ปกป้องวิทยานิพนธ์ของเขาที่มีชื่อว่า Representational State Transfer เกิดอะไรขึ้นในเวลาเพียงสิบปีและเหตุใดแนวคิดในการกำหนดรูปแบบเอกสารอิเล็กทรอนิกส์ให้เป็นมาตรฐานจึงไม่ทำให้ฉันตื่นเต้นอีกต่อไป ไม่มีอะไรสำคัญ เพียงแต่กระบวนทัศน์การรวมแอปพลิเคชันมีการเปลี่ยนแปลง
ก่อนหน้านี้เป็นยังไงบ้าง? ธนาคารแห่งหนึ่งส่งข้อความอีเมลอีกฉบับหนึ่ง (ขออภัย ตอนนั้นฉันทำงานที่ Inkombank ดังนั้นฉันจะพูดถึงธนาคารก่อน) ธนาคารที่สองได้รับข้อความและส่งใบเสร็จไปให้ ทั้งหมดนี้ได้รับการเข้ารหัสสิบครั้ง รับรองด้วยลายเซ็นดิจิทัล ฟังก์ชันแฮชของข้อความต้นฉบับรวมอยู่ในใบเสร็จรับเงิน... หมายเลขขาเข้าและขาออก การประทับเวลา (รวมถึงการเข้ารหัสด้วย) ฯลฯ ฯลฯ คำถามที่ถูกกล่าวถึงมากที่สุดในช่วงหลายปีที่ผ่านมาคือ จำเป็นต้องสร้างใบเสร็จรับเงินหรือไม่ และต้องทำอย่างไรเมื่อไม่ได้จัดส่งใบเสร็จรับเงิน โดยทั่วไปแล้ว เป็นเรื่องน่ากลัวที่ต้องจำไว้ว่ากระบวนการซิงโครไนซ์สถานะของภาพเสมือนจริงหลายภาพจากเอกสารจริงหนึ่งฉบับนั้นมีความซับซ้อนในระดับใด มันง่ายกว่าด้วยกระดาษ อย่างน้อยก็จนกระทั่งถึงการประดิษฐ์เครื่องถ่ายเอกสาร
ให้กลับไปสู่ยุคปัจจุบัน หากมีคิวข้อความเพื่อให้สามารถส่งข้อความได้อย่างปลอดภัยและเชื่อถือได้ เซอร์วิสบัสจะปรากฏขึ้นเพื่อกำจัดการแลกเปลี่ยนข้อความ และอย่าบอกฉันว่ารถบัสคันนี้คือสิ่งที่แลกเปลี่ยนข้อความ ฉันรู้สิ่งนี้เราทำเอง แต่มันก็ไม่ถูกต้องนัก แนวคิดดั้งเดิมของการให้บริการรถโดยสารโดยเฉพาะ องค์กร Service Bus (ESB) ไม่ได้เกี่ยวกับการส่งข้อความ แต่เป็นการสร้างความมั่นใจว่าแอปพลิเคชันใดๆ ไม่จำเป็นต้องกังวลเกี่ยวกับความจำเป็นในการสร้างอินสแตนซ์ออบเจ็กต์ในเครื่องของตนเอง จุดประสงค์ของการบริการคือการสามารถรับวัตถุดังกล่าวได้เสมอ หากคุณต้องการเอกสาร ให้ป้อน URL และใช้วิธีการ HTTP GET เพื่อรับและอ่านเอกสาร หากคุณต้องการเปลี่ยนเอกสาร คุณต้องเปลี่ยนเอกสารโดยใช้ URL เดียวกันโดยใช้วิธี HTTP PUT เพิ่ม POST แล้ว DELETE ถูกลบ อะไรจะง่ายกว่านี้? กำหนด URL ให้กับเอกสารของคุณ ใช้โปรโตคอลสไตล์ WebDAV เพื่อนำเอกสาร ทำงานกับเอกสาร และส่งกลับไปยังตำแหน่งเดิมในสถานะใหม่ ซึ่งเป็นสถานะเดียวกับที่กำหนดไว้เป็นสำเนาหลัก เช่น ไปยัง URL เดียวกันกับที่คุณนำไปใช้
ไม่อย่างนั้นมันเป็นวันสิ้นโลก ใบเสร็จรับเงินและการแจ้งเตือนการเปลี่ยนแปลงสถานะไม่ได้แย่นัก ความจำเป็นในการตีความฟิลด์เอกสารในลักษณะเดียวกัน และการซิงโครไนซ์หนังสืออ้างอิงนั้นเป็นปัญหา Third Street of Builders ในมอสโกและ 3rd Street of Builders ในเซนต์ปีเตอร์สเบิร์กซึ่งเป็นที่รู้จักจากภาพยนตร์หลักของปีใหม่นั้นยังห่างไกลจากสิ่งเดียวกัน บางทีหนังสืออ้างอิงเพียงเล่มเดียวที่ตีความเท่าๆ กันในแต่ละแผนกก็คือปฏิทินเกรกอเรียน แล้วฉันก็ไม่แน่ใจทั้งหมด หรืออีกตัวอย่างหนึ่ง - ชื่อของฉันในหนังสือเดินทางระหว่างประเทศไม่ตรงกับชื่อของฉันในวีซ่าอังกฤษที่ติดไว้ในหนังสือเดินทางระหว่างประเทศใบเดียวกัน หนังสือเดินทางเขียนว่า MAXIM และวีซ่าเขียนว่า MAKSIM ด้วยเหตุนี้ ฉันจึงกลัวที่จะข้ามพรมแดน :) มาเพิ่มความแตกต่างในชุดสถานะของเอกสารในระบบที่แตกต่างกัน กราฟการเปลี่ยนแปลงที่แตกต่างกัน เอกสารประกอบที่รวมชุดของเอกสารอื่น ซองจดหมายอิเล็กทรอนิกส์ ฯลฯ เราได้รับ ปัญหาของความซับซ้อนเชิงผสมผสานที่น่าทึ่ง จะเกิดอะไรขึ้นถ้าเอกสารไม่ได้ไปที่แผนกเดียว แต่ไปที่หลายแผนกพร้อมกัน? ประการหนึ่งพวกเขาจะปฏิบัติตามนั้น ประการหนึ่งพวกเขาจะปฏิเสธมัน และประการที่สามพวกเขาจะสูญเสียมันไป ดังนั้น เร็วๆ นี้ บุคลากรในกระบวนการจะเพิ่มเส้นทางให้กับเอกสารนี้ โดยแสดงในรูปแบบ BPMN สั้นๆ ในหลายสิบหน้า ข้อยกเว้น การคืน การยกเลิก ผลการตรวจสอบลายเซ็นดิจิทัลไม่ถูกต้อง ใบเสร็จรับเงินที่ไม่ได้รับ คีย์หมดอายุ... เมทริกซ์กำลังพัก (แต่โปรแกรมเมอร์ยังคงทำงานต่อไป)
บัสข้อมูลบูรณาการมีไว้สำหรับการสร้างแอปพลิเคชันคอมโพสิตที่ใช้มาตรฐานและเทคโนโลยีการโต้ตอบที่หลากหลายซึ่งสร้างขึ้นตามหลักการที่แตกต่างกัน ความสนใจเป็นพิเศษได้รับการจ่ายให้กับการรวมแอปพลิเคชันบนแพลตฟอร์ม 1C: Enterprise
รองรับมาตรฐานและสถานการณ์การรวมที่หลากหลายโดยใช้บัสข้อมูลการรวม
บ่อยครั้งเมื่อสร้างแอปพลิเคชันแบบรวม คุณต้องจัดการกับสถานการณ์ที่แอปพลิเคชันประเภทต่างๆ ได้รับการออกแบบมาเพื่อมาตรฐานและแผนการบูรณาการที่แตกต่างกัน ไม่ใช่เรื่องแปลกสำหรับสถานการณ์ที่การเปลี่ยนแปลงกลไกการรวมของแอปพลิเคชันที่มีอยู่เป็นไปไม่ได้หรือต้องใช้แรงงานมากด้วยเหตุผลหลายประการ: ขาดนักพัฒนา ขาดซอร์สโค้ด ฯลฯ บัสบูรณาการช่วยให้คุณสามารถรวมแอปพลิเคชันดังกล่าวเข้าเป็นหนึ่งเดียว ซ่อนความแตกต่างในการบูรณาการในระดับกลไกและการตั้งค่าของตัวเชื่อมต่อทั่วไปซึ่งนำไปสู่การโต้ตอบของแอปพลิเคชันไปสู่รูปแบบการรวมที่มีการควบคุมเดียว
มีตัวเชื่อมต่อประเภทต่อไปนี้ใน DATAREON ESB:
- ตัวเชื่อมต่อบริการ SOAP รวมถึงบริการเว็บ 1C:Enterprise 8
- ตัวเชื่อมต่อสำหรับบริการ REST รวมถึงบริการบนเว็บ "1C:Enterprise 8"
- ตัวเชื่อมต่อ MS SQL
- ตัวเชื่อมต่อ IBM DB2
- ตัวเชื่อมต่อออราเคิล
- ตัวเชื่อมต่อ PostgreSQL
- ตัวเชื่อมต่อ SharePoint
- ขั้วต่อ OData 1C
- ตัวเชื่อมต่อ TCP
- ขั้วต่อ Siemens Team Center
- ตัวเชื่อมต่อ SAP และอื่น ๆ
ตัวเชื่อมต่อทั้งหมดมีความสามารถในการกำหนดค่าการเชื่อมต่อกับระบบต้นทางแบบพาราเมตริกและโต้ตอบกับระบบได้
รายการตัวเชื่อมต่อที่มีอยู่มีการขยายอย่างต่อเนื่อง จำเป็นต้องมีรายการทั้งหมด ตรวจสอบกับ DATAREON.
DATAREON ESB มีกลไกที่ช่วยให้คุณพัฒนาตัวเชื่อมต่อต่างๆ ในภาษาแพลตฟอร์ม Java หรือ .Net ได้อย่างอิสระ ด้วยวิธีนี้ คุณสามารถปรับใช้สถานการณ์จำลองแบบกำหนดเองใดๆ สำหรับการเชื่อมต่อกับระบบต้นทางได้
ในความคิดของฉัน มีสองวิธีในการสร้างบัสบูรณาการระดับองค์กร:
- "จากระบบรวม";
- "จากกระบวนการที่กำลังดำเนินการอยู่"
แนวทาง "ระบบบูรณาการ"
ในกรณีนี้ บัสรวมถือเป็นการขนส่งประเภทหนึ่งที่ดำเนินการกำหนดเส้นทางและเจรจาโปรโตคอลการแลกเปลี่ยนข้อความ ข้อความทั้งหมดส่งผ่านห่วงโซ่: ช่องอินพุตของอะแดปเตอร์ระบบต้นทาง -> เราเตอร์ -> ช่องเอาต์พุตของระบบรับ ประเภทของการสื่อสารระหว่างส่วนประกอบเหล่านี้และเทคโนโลยีเฉพาะขึ้นอยู่กับว่าข้อความที่มาจากระบบต้นทางเดียวสามารถมีระบบปลายทางได้หลายระบบหรือไม่ ปริมาณงานที่คาดหวัง และวิธีการรับรองความสมบูรณ์ของข้อมูล (โดยใช้ธุรกรรมทั่วไปสำหรับระบบต้นทางทั้งหมด หรือข้อมูลเป็น ถ่ายโอนไปยังแต่ละระบบต้นทางในธุรกรรมของตนเอง)- ขึ้นอยู่กับระบบ ไม่ใช่ประเภทข้อความ โดยทั่วไป จำนวนระบบรวมจะน้อยกว่าจำนวนประเภทข้อความที่ส่งหลายเท่า
- ความง่ายในการเชื่อมต่อระบบรับสัญญาณใหม่: หากต้องการเชื่อมต่อระบบรับสัญญาณใหม่ เพียงป้อนข้อมูลลงในตารางเส้นทาง
- ความง่ายในการใช้งานระบบการตรวจสอบสำหรับโซลูชันการรวม: สามารถสร้างข้อมูลสำหรับระบบการตรวจสอบได้ในที่เดียว - ในเราเตอร์ (อย่างไรก็ตาม จุดนี้สามารถรับได้เฉพาะกับการจองเท่านั้น เนื่องจากมีข้อมูลที่สร้างขึ้นในอะแดปเตอร์เท่านั้น ของระบบบูรณาการ)
- ความง่ายในการสนับสนุนการแก้ปัญหา เนื่องจากข้อความทั้งหมดผ่านเราเตอร์ตัวเดียว ตรรกะทั้งหมดสำหรับการส่งข้อความและการติดตามการขึ้นต่อกันระหว่างข้อความจึงสามารถนำไปใช้ได้ในที่เดียว - ในเราเตอร์นี้
- การแบ่งปันระบบระหว่างนักพัฒนา เนื่องจากแกนของระบบและอะแดปเตอร์ทั้งหมดเป็นอิสระจากกัน (การสื่อสารมีให้ผ่านอินเทอร์เฟซเฉพาะและที่อธิบายไว้เท่านั้น) งานการพัฒนาจึงสามารถแบ่งระหว่างโปรแกรมเมอร์ได้ ซึ่งช่วยให้กระบวนการสร้างและการนำโซลูชันการรวมไปใช้เป็นแบบขนานได้
- โซลูชันนี้ใช้ได้กับการนำลอจิกการส่งข้อความแบบรวมศูนย์มาใช้เท่านั้น เช่น หากมีกฎการติดตามการขึ้นต่อกันและการเปลี่ยนแปลงทั่วไปสำหรับข้อความทั้งหมดหรือส่วนใหญ่ หากข้อความประเภทต่างๆ มีตรรกะที่แตกต่างกันอย่างสิ้นเชิงในการติดตามการขึ้นต่อกันและการจัดการการแลกเปลี่ยน จะต้องย้ายข้อความนั้นไปยังอะแดปเตอร์ ซึ่งจะลบล้างข้อดี 4 ไม่เช่นนั้นจะไม่สามารถนำไปใช้ได้เลย
- โครงการนี้เหมาะสำหรับการดำเนินการแลกเปลี่ยนแบบอะซิงโครนัส ในกรณีของการแลกเปลี่ยนแบบซิงโครนัสหรือแบบผสม ความซับซ้อนของการนำแนวทางนี้ไปใช้จะเพิ่มขึ้นอย่างมาก
- ประสิทธิภาพของโซลูชันอาจลดลง ตัวอย่างเช่น หากต้องส่งข้อความไปยังแต่ละระบบปลายทางในธุรกรรมที่แยกจากกัน จำเป็นต้องแยกระบบต้นทาง เคอร์เนล และระบบปลายทางด้วยคิว คิวเหล่านี้อาจกลายเป็นคอขวดของระบบได้
แนวทางที่อิงกระบวนการ
ในกรณีนี้ แต่ละกระบวนการทางธุรกิจที่ต้องมีการแลกเปลี่ยนข้อมูลระหว่างหลายระบบจะพิจารณาแยกกัน รถบัสดำเนินการแลกเปลี่ยนนี้ เหตุการณ์ที่ทริกเกอร์กระบวนการแลกเปลี่ยนคือการได้รับข้อความจากระบบต้นทาง ข้อความที่ได้รับจากระบบต้นทางจะถูกส่งไปยังระบบผู้รับตั้งแต่หนึ่งระบบขึ้นไป และไม่เพียงแต่ใช้ฟังก์ชันการขนส่งเท่านั้น แต่ยังติดตามผลลัพธ์ของการประมวลผลข้อความด้วย และข้อความที่ส่งมีความสัมพันธ์กับผู้อื่นวิธีนี้มีข้อดีดังต่อไปนี้:
- ความยืดหยุ่น แนวทางนี้ช่วยให้คุณใช้ตรรกะการแลกเปลี่ยนแยกต่างหากสำหรับข้อความแต่ละประเภทได้ ตรรกะนี้อาจไม่ใช่เรื่องเล็กน้อย
- ความซับซ้อนของการดำเนินการทั้งการแลกเปลี่ยนแบบอะซิงโครนัสและซิงโครนัสนั้นใกล้เคียงกัน
- ความเป็นอิสระของเธรดหรือในกรณีนี้การพูดคุยเกี่ยวกับกระบวนการจะถูกต้องมากกว่า การตัดสินใจทางเทคนิคระหว่างการดำเนินการตามกระบวนการแลกเปลี่ยนหนึ่งจะไม่ส่งผลกระทบต่อความซับซ้อนของการดำเนินการอีกกระบวนการหนึ่ง
วิธีนี้มีข้อเสียดังต่อไปนี้:
- ขึ้นอยู่กับประเภทข้อความ โดยทั่วไป จำนวนประเภทข้อความจะมากกว่าจำนวนระบบรวมหลายเท่า เมื่อเชื่อมต่อระบบต้นทางใหม่เข้ากับบัส จำเป็นต้องกำหนดเส้นทางข้อความตามประเภท และใช้กระบวนการแลกเปลี่ยนของตัวเองสำหรับข้อความแต่ละประเภท
- หากต้องใช้ตรรกะการแลกเปลี่ยนเดียวกันสำหรับข้อความหลายประเภท อาจมีการทำสำเนาการตั้งค่าโค้ดและ/หรือบัสได้
- กระบวนการส่งข้อความขึ้นอยู่กับอะแดปเตอร์ระบบและอาจพึ่งพาซึ่งกันและกัน รวมถึงกระบวนการให้บริการด้วย การมีอยู่ของการขึ้นต่อกันดังกล่าวจะช่วยลดระดับความขนานของกระบวนการพัฒนาและการนำโซลูชันการรวมไปใช้ นักพัฒนาส่วนประกอบบางส่วนขึ้นอยู่กับผลงานของผู้พัฒนาส่วนประกอบอื่นๆ ของโซลูชันการรวมระบบ
การเลือกแนวทางดำเนินการตามอัลกอริทึมต่อไปนี้:
- รับรายการและคำอธิบายของระบบรวมและประเภทข้อความจากนักวิเคราะห์
- รับรายการและคำอธิบายกระบวนการทางธุรกิจที่เกี่ยวข้องกับระบบที่ต้องการบูรณาการจากนักวิเคราะห์
- หากกระบวนการไม่สำคัญและมีระบบน้อยกว่าประเภทข้อความมาก การแลกเปลี่ยนเป็นแบบอะซิงโครนัสเป็นส่วนใหญ่ และจำเป็นต้องมีการถ่ายโอนข้อความหนึ่งไปยังหลายระบบด้วย - เราเลือกแนวทางแรก เราตัดสินใจเกี่ยวกับนโยบายการจัดการธุรกรรม
- หากกระบวนการเกี่ยวข้องกับการแลกเปลี่ยนแบบซิงโครนัสเป็นส่วนใหญ่ และกระบวนการมีความซับซ้อน เช่น การส่งข้อความขึ้นอยู่กับผลลัพธ์ของการประมวลผลในระบบรับจากนั้นเราเลือกวิธีที่สอง ข้อโต้แย้งที่สนับสนุนแนวทางนี้อาจเป็นข้อเท็จจริงที่ว่าจำนวนประเภทข้อความเทียบได้กับจำนวนระบบรวม
จำเป็นต้องเข้าใจอย่างชัดเจนว่าวิธีการนำไปใช้เหล่านี้ไม่ใช่ความเชื่อ ไม่จำเป็นต้องเลือกเฉพาะวิธีแรกหรือวิธีที่สองเท่านั้น สามารถรวมเข้าด้วยกันได้เสมอ รถโดยสารบริการระดับองค์กรที่ทันสมัย ( อี.เอส.บี.) อนุญาตให้คุณทำเช่นนี้
ฉันชอบข้อความ -
