เดิมที World Wide Web (WWW) ถูกสร้างขึ้นโดยผู้สร้างจินตนาการว่าเป็น "พื้นที่แบ่งปันข้อมูลที่ผู้คนและคอมพิวเตอร์สามารถสื่อสารระหว่างกัน" ดังนั้นเว็บแอปพลิเคชั่นแรกจึงเป็นไฟล์เซิร์ฟเวอร์ดั้งเดิมที่ส่งคืนเพจ HTML แบบคงที่ไปยังไคลเอนต์ที่ร้องขอ ดังนั้นเว็บจึงเริ่มต้นจากการเน้นเอกสาร

ขั้นต่อไปในการพัฒนาเว็บคือการเกิดขึ้นของแนวคิดของแอปพลิเคชัน ซึ่งใช้อินเทอร์เฟซเช่น CGI (หรือ FastCGI) และต่อมาบน ISAPI เกตเวย์ทั่วไปอินเทอร์เฟซ (CGI) เป็นอินเทอร์เฟซมาตรฐานสำหรับการทำงานกับเซิร์ฟเวอร์ที่อนุญาตให้คุณเรียกใช้แอปพลิเคชันเซิร์ฟเวอร์ที่เรียกผ่าน URL ข้อมูลอินพุตสำหรับแอปพลิเคชันดังกล่าวคือเนื้อหาของส่วนหัว HTTP (และเนื้อหาของคำขอเมื่อใช้โปรโตคอล POST) แอปพลิเคชัน CGI สร้างโค้ด HTML ที่ส่งคืนไปยังเบราว์เซอร์ ปัญหาหลักของแอปพลิเคชัน CGI คือตามคำขอของลูกค้าแต่ละราย เซิร์ฟเวอร์เรียกใช้โปรแกรม CGI แบบเรียลไทม์ โดยโหลดลงในพื้นที่ที่อยู่แยกต่างหาก

การถือกำเนิดของ Internet Server API (ISAPI) ไม่เพียงแต่แก้ปัญหาด้านประสิทธิภาพที่เกิดขึ้นกับแอปพลิเคชัน CGI เท่านั้น แต่ยังช่วยให้นักพัฒนามีอินเทอร์เฟซการเขียนโปรแกรมที่สมบูรณ์ยิ่งขึ้นอีกด้วย ISAPI DLLs อาจเชื่อมโยงกับนามสกุลไฟล์ผ่าน metabase พิเศษ กลไกทั้งสองนี้ (CGI และ ISAPI) ทำหน้าที่เป็นพื้นฐานสำหรับการสร้างแอปพลิเคชันเว็บประเภทแรกซึ่งรหัสเซิร์ฟเวอร์จะถูกดำเนินการขึ้นอยู่กับการกระทำของไคลเอนต์ ดังนั้น การสร้างเนื้อหาของเว็บเพจแบบไดนามิกจึงเกิดขึ้นได้ และเนื้อหาของเว็บก็หยุดอยู่นิ่งเฉย

อินเทอร์เฟซ ISAPI เป็นคุณลักษณะของ Microsoft ข้อมูลอินเทอร์เน็ตเซิร์ฟเวอร์ แอปพลิเคชัน ISAPI คือไลบรารีโหลดแบบไดนามิก (DLL) ที่ทำงานในพื้นที่ที่อยู่ของเว็บเซิร์ฟเวอร์ เมื่อเวลาผ่านไป เว็บเซิร์ฟเวอร์อื่นๆ ก็สามารถเรียกใช้แอปพลิเคชันที่ใช้เป็นไลบรารีได้ ในกรณีของเว็บเซิร์ฟเวอร์ Netscape อินเทอร์เฟซการเขียนโปรแกรมนี้เรียกว่า NSAPI (Netscape Server API) เว็บเซิร์ฟเวอร์ Apache ที่ได้รับความนิยมพอสมควรยังมีความสามารถในการรันแอปพลิเคชันเว็บที่ใช้เป็นไลบรารี ไลบรารีดังกล่าวเรียกว่า Apache DSO (Dynamic Shared Objects)

โดยธรรมชาติแล้วเมื่อใช้ทั้งแอปพลิเคชัน CGI และ ISAPI นักพัฒนาจะแก้ไขปัญหาเดียวกันโดยทั่วไป ดังนั้นขั้นตอนที่เป็นธรรมชาติคือการเกิดขึ้นของอินเทอร์เฟซระดับสูงใหม่ที่ทำให้งานในการสร้างโค้ด HTML ง่ายขึ้น อนุญาตให้เข้าถึงส่วนประกอบและการใช้ฐานข้อมูล . อินเทอร์เฟซนี้เป็นโมเดลออบเจ็กต์ Active Server Pages (ASP) ที่สร้างขึ้นบนพื้นฐานของตัวกรอง ISAPI

แนวคิดหลักของ ASP จากมุมมองของการสร้างอินเทอร์เฟซแอปพลิเคชันคือบนเว็บเพจมีส่วนของโค้ดที่ตีความโดยเว็บเซิร์ฟเวอร์และแทนที่จะให้ผู้ใช้ได้รับผลลัพธ์ของการรันโค้ดส่วนเหล่านี้

ไม่นานหลังจากการถือกำเนิดของ ASP เทคโนโลยีอื่น ๆ ก็ถูกสร้างขึ้นซึ่งใช้แนวคิดในการวางโค้ดที่ดำเนินการโดยเว็บเซิร์ฟเวอร์ภายในเว็บเพจ สิ่งที่มีชื่อเสียงที่สุดในปัจจุบันคือเทคโนโลยี JSP (Java Server Pages) ซึ่งมีแนวคิดหลักคือการคอมไพล์โค้ด Java (servlet) เพียงครั้งเดียวในการเข้าถึงครั้งแรก การดำเนินการตามวิธีการของเซิร์ฟเล็ตนี้และ วางผลลัพธ์ของการดำเนินการวิธีการเหล่านี้ในชุดข้อมูลที่ส่งไปยังเบราว์เซอร์

เทคโนโลยี Active Server Pages เวอร์ชันล่าสุดคือ ASP .NET ซึ่งเป็นกุญแจสำคัญในสถาปัตยกรรม Microsoft .NET Framework การใช้ ASP .NET คุณสามารถสร้างแอปพลิเคชันเว็บและบริการบนเว็บที่ไม่เพียงแต่ช่วยให้คุณสามารถใช้การสร้างเพจ HTML แบบไดนามิกเท่านั้น แต่ยังรวมเข้ากับส่วนประกอบเซิร์ฟเวอร์และสามารถใช้เพื่อแก้ไขปัญหาทางธุรกิจที่หลากหลายที่เกิดขึ้นก่อนนักพัฒนาซอฟต์แวร์สมัยใหม่ แอปพลิเคชันบนเว็บ

โดยทั่วไป ไคลเอนต์เว็บเซิร์ฟเวอร์ไม่เพียงแต่จะเป็นคอมพิวเตอร์ส่วนบุคคลที่ติดตั้งเว็บเบราว์เซอร์ปกติเท่านั้น นอกเหนือจากการใช้อุปกรณ์พกพาอย่างแพร่หลายแล้ว ปัญหาในการจัดเตรียมข้อมูลให้กับเว็บเซิร์ฟเวอร์ที่อุปกรณ์เหล่านี้สามารถตีความได้ก็เกิดขึ้นเช่นกัน เนื่องจากอุปกรณ์มือถือมีลักษณะที่แตกต่างจากคอมพิวเตอร์ส่วนบุคคล (ขนาดหน้าจอที่จำกัด หน่วยความจำขนาดเล็ก และบ่อยครั้งที่ไม่สามารถแสดงสิ่งอื่นใดนอกจากข้อความขาวดำสองสามบรรทัด) จึงมีโปรโตคอลการถ่ายโอนข้อมูลอื่นๆ สำหรับอุปกรณ์เหล่านั้น (WAP - Wireless Access Protocol) และภาษามาร์กอัปที่เกี่ยวข้อง (WML - ภาษามาร์กอัปไร้สาย, СHTML - Compact HTML ฯลฯ ) ในกรณีนี้ งานเกิดขึ้นจากการถ่ายโอนข้อมูลไปยังอุปกรณ์มือถือในรูปแบบที่เหมาะสม (และมีไซต์พิเศษสำหรับจุดประสงค์นี้) หรือประเภทของอุปกรณ์ที่ดูเหมือนสะดวกกว่าจะได้รับการยอมรับในขณะที่ติดต่อกับเซิร์ฟเวอร์และ เอกสารต้นฉบับจะถูกแปลง (เช่น ในรูปแบบ XML) เป็นรูปแบบที่ต้องการ อุปกรณ์โทรศัพท์(เช่น การใช้การแปลง XSLT)

อีกวิธีหนึ่งในการสนับสนุนไคลเอนต์ประเภทต่างๆ คือการสร้างส่วนประกอบเซิร์ฟเวอร์ "อัจฉริยะ" ที่สามารถสร้างโค้ดที่แตกต่างกันขึ้นอยู่กับประเภทของไคลเอนต์ โดยเฉพาะอย่างยิ่งแนวทางนี้ถูกนำไปใช้ใน Microsoft ASP .NET

อีกทิศทางหนึ่งในการพัฒนาส่วนไคลเอนต์ของแอปพลิเคชันเว็บคือการวางตำแหน่งของตรรกะแอปพลิเคชันบางส่วน (เช่นการตรวจสอบความถูกต้องของข้อมูลอินพุต) ในตัวเว็บเบราว์เซอร์เอง โดยเฉพาะอย่างยิ่ง เว็บเบราว์เซอร์สมัยใหม่มีความสามารถในการแปลภาษาสคริปต์ (VBScript, JavaScript) ซึ่งเป็นโค้ดที่ฝังอยู่ในเว็บเพจเช่นเดียวกับโค้ด ASP แต่ไม่ได้ตีความโดยเว็บเซิร์ฟเวอร์ แต่โดยเบราว์เซอร์และ ดังนั้นจึงดำเนินการบนอุปกรณ์ไคลเอนต์ นอกจาก, เบราว์เซอร์ที่ทันสมัยสามารถแสดงและดำเนินการแอปเพล็ต Java - แอปพลิเคชัน Java พิเศษที่ผู้ใช้ได้รับเป็นส่วนหนึ่งของเว็บเพจและเบราว์เซอร์บางตัวยังสามารถทำหน้าที่เป็นคอนเทนเนอร์สำหรับการควบคุม ActiveX - เซิร์ฟเวอร์ COM พิเศษที่ทำงานในพื้นที่ที่อยู่ของเบราว์เซอร์ซึ่งได้รับเช่นกัน เป็นส่วนหนึ่งของ หน้าเว็บ. ทั้งแอปเพล็ต Java และตัวควบคุม ActiveX สามารถใช้ฟังก์ชันได้เกือบทุกฟังก์ชัน

โปรดทราบว่าเมื่อปริมาณข้อมูลที่ใช้และจำนวนผู้เยี่ยมชมเว็บไซต์เพิ่มขึ้น ข้อกำหนดด้านความน่าเชื่อถือ ประสิทธิภาพ และความสามารถในการปรับขนาดของเว็บแอปพลิเคชันก็เพิ่มขึ้นเช่นกัน ขั้นต่อไปในวิวัฒนาการของแอปพลิเคชันดังกล่าวคือการแยกตรรกะทางธุรกิจที่ใช้ในเว็บแอปพลิเคชัน และบ่อยครั้งที่การประมวลผลข้อมูลและบริการธุรกรรมออกจากอินเทอร์เฟซ ในกรณีนี้ ส่วนการนำเสนอที่เรียกว่ามักจะยังคงอยู่ในเว็บแอปพลิเคชัน และตรรกะทางธุรกิจ การประมวลผลข้อมูล และการดำเนินการธุรกรรมจะถูกถ่ายโอนไปยัง เซิร์ฟเวอร์แอปพลิเคชันในรูปแบบของวัตถุทางธุรกิจ ขึ้นอยู่กับประเภท แอปพลิเคชันเซิร์ฟเวอร์ออบเจ็กต์ทางธุรกิจเหล่านี้อาจเป็นเซิร์ฟเวอร์ COM ที่ดำเนินการด้วยตนเอง เซิร์ฟเวอร์ CORBA หรือออบเจ็กต์ COM+ ที่ทำงานโดยใช้บริการ ส่วนประกอบของวินโดวส์ 2000 หรือปฏิบัติการ EJBs (Enterprise Java Beans) แอปพลิเคชันเซิร์ฟเวอร์รองรับข้อกำหนด J2EE (Java 2 Enterprise Edition) เช่น กลไกการเข้าถึงข้อมูลออบเจ็กต์ดังกล่าวสามารถใช้ OLE DB, ODBC, JDBC ได้ (ขึ้นอยู่กับวิธีการนำออบเจ็กต์ทางธุรกิจไปใช้)

บ่อยครั้งที่ออบเจ็กต์ทางธุรกิจดังกล่าวให้การเข้าถึงข้อมูลจากระบบข้อมูลขององค์กรหรือใช้ฟังก์ชันการทำงานบางส่วน พวกเขามักจะอนุญาตให้รวมเว็บไซต์เข้ากับระบบ CRM (การจัดการลูกค้าสัมพันธ์) หรือ ERP (การวางแผนทรัพยากรองค์กร) จัดเก็บข้อมูลเกี่ยวกับผู้เยี่ยมชมไซต์ในระบบองค์กร และให้ข้อมูลผู้มีโอกาสเป็นลูกค้าเกี่ยวกับผลิตภัณฑ์ที่มีอยู่สำหรับการสั่งซื้อ

เนื่องจากอินเทอร์เน็ตสมัยใหม่ไม่ใช่วิธีการแสดงสถานะของ บริษัท ในตลาดหรือเครื่องมือทางการตลาดมากนัก แต่เป็นเครื่องมือในการทำธุรกิจ งานในการจัดการความสัมพันธ์ดังกล่าวกับลูกค้าผ่านทางอินเทอร์เน็ตเมื่อการขายสินค้าและบริการกลายเป็น ค่อนข้างสำคัญ และที่นี่โซลูชั่นสำหรับอีคอมเมิร์ซประเภท "องค์กรถึงลูกค้า" (B2C - ธุรกิจกับผู้บริโภค) มีความสำคัญมาก งานที่สำคัญไม่น้อยคือการรวมแอปพลิเคชันเว็บเข้ากับข้อมูลและแอปพลิเคชันของพันธมิตรเพื่อดำเนินการตามโครงการระดับองค์กรต่อองค์กร (B2B - ธุรกิจกับธุรกิจ) ซึ่งช่วยให้สามารถสรุปธุรกรรมการค้าระหว่างองค์กร แลกเปลี่ยนแคตตาล็อกผลิตภัณฑ์ ดำเนินการ การประมูลการสร้างแพลตฟอร์มการซื้อขายทางอิเล็กทรอนิกส์

โปรดทราบว่าการเป็น ส่วนสำคัญวิธีแก้ปัญหาดังกล่าว เว็บเซิร์ฟเวอร์จะต้องไม่เพียงแต่สามารถรันแอพพลิเคชั่นและโต้ตอบด้วยเท่านั้น แอปพลิเคชันเซิร์ฟเวอร์แต่ยังใช้บริการบูรณาการ บริการจัดการแอปพลิเคชันและข้อมูล รวมถึงบริการสำหรับนักพัฒนาอีกด้วย

ขั้นตอนต่อไปในวิวัฒนาการของเว็บแอปพลิเคชัน นอกเหนือจากการเข้าถึงข้อมูลองค์กรและคู่ค้าแล้ว ก็คือการเข้าถึงแอปพลิเคชันระดับองค์กร เพื่อแก้ไขปัญหาในการรวมเว็บแอปพลิเคชันเข้ากับระบบข้อมูลภายในขององค์กรและกับแอปพลิเคชันที่ให้ความมั่นใจในการโต้ตอบกับลูกค้าและคู่ค้า โซลูชั่นพิเศษเรียกว่าพอร์ทัลองค์กร

บ่อยครั้งที่โซลูชันพอร์ทัลส่วนหนึ่งมีเครื่องมือสำหรับจัดการเนื้อหาของเว็บไซต์ - อย่างไรก็ตาม ปริมาณข้อมูลที่มีให้กับผู้ใช้ที่ใช้เว็บไซต์ของบริษัทขนาดใหญ่และพอร์ทัลในขณะนี้ทำให้ไม่สามารถจัดการข้อมูลนี้ "ด้วยตนเอง" ได้

โดยสรุปข้างต้น เราสามารถเน้นคุณสมบัติหลักของสถาปัตยกรรมเว็บ [, ]:

• ไม่จำเป็นต้องใช้ซอฟต์แวร์เพิ่มเติมบนฝั่งไคลเอ็นต์ - สิ่งนี้ช่วยให้คุณสามารถใช้งานส่วนไคลเอนต์บนทุกแพลตฟอร์มได้โดยอัตโนมัติ
• ความสามารถในการเชื่อมต่อลูกค้าได้ไม่จำกัดจำนวน
• ด้วยตำแหน่งจัดเก็บข้อมูลเพียงแห่งเดียวและการมีระบบจัดการฐานข้อมูล ทำให้มั่นใจได้ในข้อกำหนดขั้นต่ำสำหรับการรักษาความสมบูรณ์ของข้อมูล
• ความพร้อมใช้งานเมื่อเซิร์ฟเวอร์และช่องทางการสื่อสารทำงาน
• ไม่พร้อมใช้งานหากเซิร์ฟเวอร์หรือช่องทางการสื่อสารไม่ทำงาน
• ความเร็วของเว็บเซิร์ฟเวอร์และช่องทางการรับส่งข้อมูลค่อนข้างต่ำ
• เกี่ยวกับปริมาณข้อมูล สถาปัตยกรรมของระบบเว็บไม่มีข้อจำกัดที่สำคัญ

แผนผังสถาปัตยกรรมดังกล่าว (ในเวอร์ชันสามระดับ) สามารถแสดงได้ดังแสดงในรูปที่ 1 5.9.

ข้าว. 5.9.

5.1.8. สถาปัตยกรรมเชิงบริการ

การแก้ปัญหาต่างๆ ที่อธิบายไว้ข้างต้นที่เกิดขึ้นเมื่อสร้างเว็บแอปพลิเคชันสมัยใหม่ ขณะนี้เริ่มถูกกำหนดให้กับบริการเว็บแล้ว - แพลตฟอร์ม โมเดลออบเจ็กต์ และส่วนประกอบซอฟต์แวร์อิสระของไคลเอนต์ที่สามารถเรียกจากแอปพลิเคชันเว็บไคลเอนต์ (เช่นเดียวกับจากเว็บ บริการเอง ) ผ่านโปรโตคอล SOAP ตามโปรโตคอล HTTP และภาษา XML WSDL ภาษาคล้าย XML ใช้เพื่ออธิบายบริการบนเว็บ และอินเทอร์เฟซ UDDI ใช้เพื่อจัดระเบียบการลงทะเบียนบริการเว็บ ซึ่งนักพัฒนาและบริษัทสามารถค้นหาบริการที่ต้องการได้ เช่นเดียวกับการเผยแพร่ข้อมูลเกี่ยวกับบริการของตน

การสนับสนุนบริการเว็บได้กลายเป็นหนึ่งในทิศทางเชิงกลยุทธ์หลักสำหรับหลายบริษัทที่เชี่ยวชาญด้านการผลิต แอปพลิเคชันเซิร์ฟเวอร์, ระบบการจัดการฐานข้อมูลและเครื่องมือในการพัฒนาแอพพลิเคชั่น

(SOA สถาปัตยกรรมเชิงบริการ)– แนวทางแบบโมดูลาร์ในการพัฒนาซอฟต์แวร์ โดยอิงจากการใช้บริการที่มีอินเทอร์เฟซมาตรฐาน

OASIS (Organization for Open Standards for Structured Information) กำหนด SOA ไว้ดังนี้ (OASIS Reference Model for Service Oriented Architecture V 1.0): สถาปัตยกรรมเชิงบริการเป็นกระบวนทัศน์ในการจัดระเบียบและใช้ทรัพยากรสารสนเทศแบบกระจาย เช่น แอปพลิเคชันและข้อมูล ซึ่งอยู่ภายใต้ความรับผิดชอบของเจ้าของที่แตกต่างกัน เพื่อให้บรรลุผลลัพธ์ที่ต้องการโดยผู้บริโภค ซึ่งอาจเป็น: ผู้ใช้หรือแอปพลิเคชันอื่นๆ

SOA ยึดหลักการของการนำองค์ประกอบ IT ที่ใช้งานได้กลับมาใช้ใหม่ ขจัดความซ้ำซ้อนของฟังก์ชันการทำงานในซอฟต์แวร์ รวมกระบวนการปฏิบัติงานมาตรฐานเข้าด้วยกัน ทำให้มั่นใจได้ถึงการถ่ายโอนรูปแบบการดำเนินงานของบริษัทไปยังกระบวนการแบบรวมศูนย์ และ องค์กรที่ทำงานบนพื้นฐานแพลตฟอร์มบูรณาการทางอุตสาหกรรม

ส่วนประกอบของโปรแกรมสามารถกระจายไปตามโหนดเครือข่ายต่างๆ และนำเสนอเป็นบริการแอปพลิเคชันที่เป็นอิสระ เชื่อมโยงอย่างหลวมๆ และเปลี่ยนได้ แพคเกจซอฟต์แวร์ที่พัฒนาตาม SOA มักจะถูกนำมาใช้เป็นชุดของบริการเว็บที่บูรณาการโดยใช้โปรโตคอลมาตรฐานที่รู้จักกันดี (SOAP, WSDL ฯลฯ)

อินเทอร์เฟซส่วนประกอบของโปรแกรม SOA จัดให้มีการสรุปรายละเอียดการใช้งานของส่วนประกอบเฉพาะ (ระบบปฏิบัติการ แพลตฟอร์ม ภาษาการเขียนโปรแกรม ผู้จำหน่าย ฯลฯ) จากส่วนประกอบอื่นๆ ดังนั้น SOA จึงมอบวิธีการที่ยืดหยุ่นและสง่างามในการรวมและนำส่วนประกอบกลับมาใช้ใหม่เพื่อสร้างระบบซอฟต์แวร์แบบกระจายที่ซับซ้อน

SOA ได้พิสูจน์ตัวเองแล้วว่ามีประโยชน์สำหรับการสร้างแอปพลิเคชันซอฟต์แวร์องค์กรขนาดใหญ่ นักพัฒนาและผู้บูรณาการจำนวนหนึ่งเสนอเครื่องมือและโซลูชันที่ใช้ SOA (เช่น แพลตฟอร์ม ไอบีเอ็ม เว็บสเฟียร์, Oracle/BEA Aqualogic, Microsoft Windows Communication Foundation, SAP NetWeaver, IVK Jupiter, TIBCO, Diasoft)

เป้าหมายหลักของการใช้ SOA สำหรับระบบข้อมูลขนาดใหญ่ ระดับองค์กร และสูงกว่าคือ:

• ลดต้นทุนในการพัฒนาแอปพลิเคชันโดยปรับปรุงกระบวนการพัฒนาให้มีประสิทธิภาพ
• เพิ่มประสิทธิภาพการใช้โค้ดซ้ำ
• ความเป็นอิสระจากแพลตฟอร์ม เครื่องมือ และภาษาที่ใช้ในการพัฒนา
• เพิ่มความสามารถในการปรับขนาดของระบบที่สร้างขึ้น
• ปรับปรุงการควบคุมของระบบที่สร้างขึ้น

หลักการของ SOA:

• สถาปัตยกรรมเช่นนี้ไม่ได้เชื่อมโยงกับเทคโนโลยีใดโดยเฉพาะ
• ความเป็นอิสระขององค์กรระบบจากแพลตฟอร์มคอมพิวเตอร์ที่ใช้
• ความเป็นอิสระขององค์กรระบบจากภาษาโปรแกรมที่ใช้
• การใช้บริการที่เป็นอิสระจาก การใช้งานเฉพาะพร้อมอินเทอร์เฟซการเข้าถึงที่สม่ำเสมอ
• การจัดบริการเป็นส่วนประกอบที่เชื่อมโยงอย่างหลวมๆ สำหรับระบบอาคาร

สถาปัตยกรรมไม่ได้เชื่อมโยงกับเทคโนโลยีเฉพาะใดๆ สามารถนำไปใช้งานได้โดยใช้เทคโนโลยีที่หลากหลาย รวมถึงเทคโนโลยี เช่น REST, RPC, DCOM, CORBA หรือบริการบนเว็บ SOA อาจถูกนำมาใช้โดยใช้หนึ่งในโปรโตคอลเหล่านี้ และอาจใช้กลไกเพิ่มเติม ตัวอย่างเช่น ระบบไฟล์เพื่อการแลกเปลี่ยนข้อมูล

สิ่งสำคัญที่ทำให้ SOA แตกต่างคือการใช้บริการอิสระที่มีอินเทอร์เฟซที่กำหนดไว้อย่างดีซึ่งสามารถเรียกใช้งานได้ด้วยวิธีมาตรฐานโดยมีเงื่อนไขว่าบริการจะไม่ทราบอะไรล่วงหน้าเกี่ยวกับแอปพลิเคชันที่จะเรียกใช้ พวกเขาและแอปพลิเคชันไม่ทราบว่าบริการทำงานอย่างไร

SOA ยังถือเป็นรูปแบบสถาปัตยกรรมระบบข้อมูลที่ช่วยให้คุณสร้างแอปพลิเคชันนั้นได้ สร้างโดยการผสมผสานระหว่างบริการเชื่อมต่อและโต้ตอบอย่างหลวมๆ บริการเหล่านี้โต้ตอบตามอินเทอร์เฟซที่ไม่ขึ้นอยู่กับแพลตฟอร์มและไม่ขึ้นอยู่กับภาษาที่กำหนดไว้อย่างเคร่งครัด (เช่น WSDL) คำจำกัดความของอินเทอร์เฟซจะซ่อนการใช้งานบริการเฉพาะภาษา

ดังนั้น ระบบที่ใช้ SOA จึงสามารถเป็นอิสระจากเทคโนโลยีและแพลตฟอร์มการพัฒนา (เช่น Java, .NET เป็นต้น) ตัวอย่างเช่น บริการที่เขียนด้วยภาษา C# ที่ทำงานบนแพลตฟอร์ม .Net และบริการที่เขียนด้วยภาษา Java ที่ทำงานบนแพลตฟอร์ม Java EE สามารถเรียกใช้โดยแอปพลิเคชันคอมโพสิตทั่วไปที่มีความสำเร็จเท่าเทียมกัน แอปพลิเคชันที่ทำงานบนบางแพลตฟอร์มสามารถเรียกใช้บริการที่ทำงานบนแพลตฟอร์มอื่นได้ทำให้ง่ายขึ้น ใช้ซ้ำส่วนประกอบ

, , เทอร์มินัล , เซิร์ฟเวอร์แอปพลิเคชัน, เซิร์ฟเวอร์ฐานข้อมูล, สถาปัตยกรรมระบบแบบกระจาย, , สถาปัตยกรรมเชิงบริการ.

ซอฟต์แวร์โอเพ่นซอร์สได้กลายเป็นส่วนสำคัญในการสร้างเว็บไซต์ที่ใหญ่ที่สุดในโลกบางแห่ง ด้วยการเติบโตของเว็บไซต์เหล่านี้ แนวทางปฏิบัติที่ดีที่สุดและแนวปฏิบัติสำหรับสถาปัตยกรรมได้เกิดขึ้น บทนี้มีจุดมุ่งหมายเพื่อครอบคลุมประเด็นสำคัญบางประการที่ต้องพิจารณาเมื่อออกแบบเว็บไซต์ขนาดใหญ่ รวมถึงองค์ประกอบพื้นฐานบางส่วนที่ใช้ในการบรรลุเป้าหมายเหล่านี้

จุดเน้นของบทนี้คือการวิเคราะห์ระบบบนเว็บ แม้ว่าเนื้อหาบางส่วนอาจถูกคาดการณ์ไปยังระบบแบบกระจายอื่นๆ

1.1 หลักการสร้างระบบเว็บแบบกระจาย

การสร้างและจัดการเว็บไซต์หรือแอปพลิเคชันที่ปรับขนาดได้หมายความว่าอย่างไร ในระดับดั้งเดิม นี่เป็นเพียงการเชื่อมโยงผู้ใช้เข้ากับ ทรัพยากรระยะไกลผ่านทางอินเทอร์เน็ต และทรัพยากรหรือการเข้าถึงทรัพยากรเหล่านี้ซึ่งกระจายอยู่บนเซิร์ฟเวอร์จำนวนมากและเป็นลิงก์ที่ช่วยให้มั่นใจถึงความสามารถในการปรับขนาดของเว็บไซต์

เช่นเดียวกับสิ่งต่างๆ ในชีวิต การใช้เวลาล่วงหน้าในการวางแผนสร้างบริการเว็บสามารถช่วยได้ในภายหลัง การทำความเข้าใจข้อควรพิจารณาและข้อดีข้อเสียบางประการของเว็บไซต์ขนาดใหญ่สามารถให้การตัดสินใจที่ชาญฉลาดยิ่งขึ้นเมื่อสร้างเว็บไซต์ขนาดเล็ก ด้านล่างนี้เป็นหลักการสำคัญบางประการที่มีอิทธิพลต่อการออกแบบระบบเว็บขนาดใหญ่:

• มีจำหน่าย:ระยะเวลา สภาพการทำงานเว็บไซต์มีความสำคัญต่อชื่อเสียงและการทำงานของหลายบริษัท สำหรับผู้ค้าปลีกออนไลน์รายใหญ่บางราย การไม่สามารถให้บริการได้เพียงไม่กี่นาทีอาจส่งผลให้สูญเสียรายได้หลายพันหรือหลายล้านดอลลาร์ ดังนั้นการพัฒนาระบบให้พร้อมใช้งานอยู่เสมอและทนทานต่อความล้มเหลวจึงเป็นทั้งข้อกำหนดพื้นฐานทางธุรกิจและเทคโนโลยี ความพร้อมใช้งานสูงในระบบแบบกระจายต้องพิจารณาอย่างรอบคอบถึงความซ้ำซ้อนสำหรับส่วนประกอบหลัก ฟื้นตัวอย่างรวดเร็วหลังจากระบบขัดข้องบางส่วนและความสามารถลดลงอย่างราบรื่นเมื่อเกิดปัญหา
• ผลงาน:ประสิทธิภาพของเว็บไซต์ได้กลายเป็น ตัวบ่งชี้ที่สำคัญสำหรับไซต์ส่วนใหญ่ ความเร็วเว็บไซต์ส่งผลกระทบต่อประสบการณ์และความพึงพอใจของผู้ใช้ เช่นเดียวกับการจัดอันดับเครื่องมือค้นหา ซึ่งเป็นปัจจัยที่ส่งผลโดยตรงต่อการรักษาผู้ชมและรายได้ ด้วยเหตุนี้ สิ่งสำคัญคือการสร้างระบบที่ได้รับการปรับให้เหมาะสมเพื่อการตอบสนองที่รวดเร็วและความหน่วงต่ำ
• ความน่าเชื่อถือ:ระบบจะต้องเชื่อถือได้เช่นนั้น คำขอเฉพาะเมื่อได้รับข้อมูลก็จะส่งคืนข้อมูลบางอย่างอย่างสม่ำเสมอ ในกรณีที่ข้อมูลเปลี่ยนแปลงหรืออัพเดต คำขอเดียวกันควรส่งคืนข้อมูลใหม่ ผู้ใช้จำเป็นต้องรู้ว่าหากมีสิ่งใดถูกบันทึกหรือเก็บไว้ในระบบ พวกเขาสามารถมั่นใจได้ว่าสิ่งนั้นจะยังคงอยู่เพื่อเรียกค้นในภายหลัง
• ความสามารถในการขยายขนาด:เมื่อพูดถึงระบบแบบกระจายขนาดใหญ่ ขนาดเป็นเพียงรายการเดียวในรายการที่ต้องพิจารณา สิ่งที่สำคัญไม่แพ้กันคือความพยายามในการเพิ่มความสามารถในการประมวลผล ปริมาณมากโหลด ซึ่งโดยทั่วไปเรียกว่าความสามารถในการปรับขนาดของระบบ ความสามารถในการปรับขนาดอาจอ้างอิงถึงพารามิเตอร์ต่างๆ ของระบบ เช่น จำนวนการรับส่งข้อมูลเพิ่มเติมที่ระบบสามารถรองรับได้ ความง่ายในการเพิ่มความจุในการจัดเก็บข้อมูล หรือปริมาณธุรกรรมอื่นๆ ที่สามารถประมวลผลได้มากเพียงใด
• การควบคุม:การออกแบบระบบที่ใช้งานง่ายเป็นอีกปัจจัยสำคัญ ความสามารถในการจัดการระบบเท่ากับความสามารถในการปรับขนาดของการดำเนินการ "บำรุงรักษา" และ "อัปเดต" เพื่อให้มั่นใจถึงความสามารถในการจัดการจำเป็นต้องพิจารณาความง่ายในการวินิจฉัยและทำความเข้าใจปัญหาที่เกิดขึ้นความง่ายในการอัปเดตหรือแก้ไขและความง่ายในการใช้งานของระบบ (นั่นคือมันทำงานตามที่คาดไว้โดยไม่มีความล้มเหลวหรือข้อยกเว้นใช่ไหม)
• ราคา:ค่าใช้จ่ายก็คือ ปัจจัยสำคัญ. เห็นได้ชัดว่าอาจรวมถึงค่าใช้จ่ายด้านฮาร์ดแวร์และซอฟต์แวร์ด้วย แต่การพิจารณาด้านอื่นๆ ที่จำเป็นในการปรับใช้และบำรุงรักษาระบบก็เป็นสิ่งสำคัญเช่นกัน ระยะเวลาที่นักพัฒนาต้องใช้ในการสร้างระบบ จำนวนความพยายามในการดำเนินงานที่จำเป็นในการทำให้ระบบพร้อมใช้งาน และแม้แต่ระดับการฝึกอบรมที่เหมาะสม ล้วนต้องจัดเตรียมไว้ให้ ต้นทุนแสดงถึงต้นทุนรวมในการเป็นเจ้าของ

แต่ละหลักการเหล่านี้เป็นพื้นฐานในการตัดสินใจออกแบบ สถาปัตยกรรมเว็บแบบกระจาย. อย่างไรก็ตาม พวกเขายังสามารถขัดแย้งกันเองได้ เนื่องจากการบรรลุเป้าหมายของฝ่ายหนึ่งต้องแลกมากับการละเลยอีกฝ่ายหนึ่ง ตัวอย่างง่ายๆ: การเลือกเพิ่มเซิร์ฟเวอร์หลายเครื่องเป็นโซลูชันด้านประสิทธิภาพ (ความสามารถในการปรับขนาด) สามารถเพิ่มต้นทุนการจัดการ (คุณต้องใช้งานเซิร์ฟเวอร์เพิ่มเติม) และการซื้อเซิร์ฟเวอร์

เมื่อพัฒนาเว็บแอปพลิเคชันประเภทใดก็ตาม สิ่งสำคัญคือต้องพิจารณาหลักการสำคัญเหล่านี้ แม้ว่าจะเป็นการยืนยันว่าโครงการสามารถเสียสละหนึ่งหรือหลายอย่างก็ตาม

1.2 พื้นฐาน

เมื่อพิจารณาสถาปัตยกรรมระบบ มีหลายประเด็นที่ต้องแก้ไข เช่น ส่วนประกอบใดคุ้มค่าที่จะใช้ ส่วนประกอบแต่ละส่วนเข้ากันได้อย่างไร และข้อแลกเปลี่ยนใดบ้างที่สามารถทำได้ การลงทุนเพื่อขยายขนาดโดยไม่จำเป็นต้องชัดเจนไม่ใช่การตัดสินใจทางธุรกิจที่ชาญฉลาด อย่างไรก็ตาม การคิดล่วงหน้าในการวางแผนสามารถช่วยประหยัดเวลาและทรัพยากรได้มากในอนาคต

ในส่วนนี้เน้นที่ปัจจัยพื้นฐานบางประการที่มีความสำคัญต่อเว็บแอปพลิเคชันขนาดใหญ่เกือบทั้งหมด: บริการ,
ความซ้ำซ้อน, การแบ่งส่วน, และ การจัดการความล้มเหลว. แต่ละปัจจัยเหล่านี้เกี่ยวข้องกับการเลือกและการแลกเปลี่ยน โดยเฉพาะอย่างยิ่งในบริบทของหลักการที่อธิบายไว้ในส่วนก่อนหน้า เพื่อชี้แจงเราขอยกตัวอย่าง

ตัวอย่าง: แอปพลิเคชันโฮสต์รูปภาพ

คุณอาจเคยโพสต์ภาพออนไลน์มาก่อน สำหรับไซต์ขนาดใหญ่ที่เก็บและจัดส่งรูปภาพจำนวนมาก มีความท้าทายในการสร้างสถาปัตยกรรมที่คุ้มค่าและเชื่อถือได้สูงซึ่งมีเวลาแฝงในการตอบสนองต่ำ (เรียกข้อมูลได้อย่างรวดเร็ว)

ลองนึกภาพระบบที่ผู้ใช้สามารถอัปโหลดภาพไปยังเซิร์ฟเวอร์กลาง และสามารถขอรูปภาพผ่านไซต์ลิงก์หรือ API ได้ ซึ่งคล้ายกับ Flickr หรือ Picasa เพื่อให้คำอธิบายง่ายขึ้น สมมติว่าแอปพลิเคชันนี้มีสองงานหลัก: ความสามารถในการอัปโหลด (เขียน) รูปภาพไปยังเซิร์ฟเวอร์และการขอรูปภาพ แน่นอนว่าการโหลดอย่างมีประสิทธิภาพถือเป็นเกณฑ์สำคัญ แต่จะให้ความสำคัญเป็นอันดับแรก จัดส่งที่รวดเร็วตามที่ผู้ใช้ร้องขอ (เช่น รูปภาพอาจถูกขอให้แสดงบนหน้าเว็บหรือโดยแอปพลิเคชันอื่น) ฟังก์ชันการทำงานนี้คล้ายกับสิ่งที่เว็บเซิร์ฟเวอร์หรือเซิร์ฟเวอร์ Edge ของ Content Delivery Network (CDN) สามารถให้ได้ โดยทั่วไปเซิร์ฟเวอร์ CDN จะจัดเก็บออบเจ็กต์ข้อมูลไว้ในหลายตำแหน่ง ทำให้ใกล้ชิดกับผู้ใช้ทางภูมิศาสตร์/ทางกายภาพมากขึ้น ส่งผลให้ประสิทธิภาพดีขึ้น

ประเด็นสำคัญอื่น ๆ ของระบบ:

• จำนวนรูปภาพที่จัดเก็บสามารถไม่จำกัด ดังนั้นจึงต้องพิจารณาความสามารถในการปรับขนาดพื้นที่เก็บข้อมูลจากมุมมองนี้
• การดาวน์โหลด/คำขอรูปภาพควรมีเวลาแฝงต่ำ
• หากผู้ใช้อัปโหลดรูปภาพไปยังเซิร์ฟเวอร์ ข้อมูลจะต้องไม่เสียหายและเข้าถึงได้เสมอ
• ระบบจะต้องง่ายต่อการบำรุงรักษา (การจัดการ)
• เนื่องจากการโฮสต์รูปภาพไม่ได้สร้างผลกำไรมากนัก ระบบจึงต้องมีความคุ้มค่า

ปัญหาที่อาจเกิดขึ้นอีกประการหนึ่งของการออกแบบนี้คือ เว็บเซิร์ฟเวอร์ เช่น Apache หรือ lighttpd มักจะมีขีดจำกัดสูงสุดเกี่ยวกับจำนวนการเชื่อมต่อพร้อมกันที่สามารถให้บริการได้ (ค่าเริ่มต้นคือประมาณ 500 แต่อาจสูงกว่านี้ได้มาก) และมีปริมาณการรับส่งข้อมูลสูง การบันทึกสามารถใช้ขีดจำกัดนี้ได้อย่างรวดเร็ว เนื่องจากการอ่านสามารถเป็นแบบอะซิงโครนัสหรือใช้ประโยชน์จากการเพิ่มประสิทธิภาพอื่นๆ เช่น การบีบอัด gzip หรือการแบ่งส่วน เว็บเซิร์ฟเวอร์จึงสามารถสลับการอ่านฟีดได้เร็วขึ้น และสลับระหว่างไคลเอนต์ โดยให้บริการคำขอมากกว่า จำนวนสูงสุดการเชื่อมต่อ (ด้วย Apache และจำนวนการเชื่อมต่อสูงสุดที่ตั้งไว้ที่ 500 จึงค่อนข้างเป็นไปได้ที่จะให้บริการคำขออ่านหลายพันคำขอต่อวินาที) ในทางกลับกัน บันทึกมีแนวโน้มที่จะเปิดการเชื่อมต่อไว้ตลอดระยะเวลาของการดาวน์โหลด ดังนั้น การถ่ายโอนไฟล์ขนาด 1 MB ไปยังเซิร์ฟเวอร์อาจใช้เวลานานกว่า 1 วินาทีบนเครือข่ายภายในบ้านส่วนใหญ่ ส่งผลให้เว็บเซิร์ฟเวอร์สามารถประมวลผลรายการพร้อมกันเหล่านี้ได้เพียง 500 รายการเท่านั้น

รูปที่ 1.2: การแยกการอ่าน/การเขียน

การคาดการณ์ปัญหาที่อาจเกิดขึ้นนี้ชี้ให้เห็นถึงความจำเป็นในการแยกการอ่านและการเขียนรูปภาพออกเป็นบริการอิสระ ดังแสดงใน สิ่งนี้จะไม่เพียงช่วยให้เราสามารถปรับขนาดแต่ละรายการแยกกัน (เนื่องจากมีแนวโน้มว่าเราจะทำเช่นนั้นเสมอไป) การอ่านเพิ่มเติมกว่าบันทึก) แต่ยังต้องระวังสิ่งที่เกิดขึ้นในแต่ละบริการด้วย สุดท้ายจะแยกแยะปัญหาที่อาจเกิดขึ้นในอนาคต ทำให้ง่ายต่อการวินิจฉัยและประเมินปัญหาการเข้าถึงการอ่านที่ช้า

ข้อดีของแนวทางนี้คือเราสามารถแก้ไขปัญหาได้อย่างอิสระโดยไม่ต้องกังวลกับการบันทึกและดึงภาพใหม่ในบริบทเดียวกัน บริการทั้งสองนี้ยังคงใช้คลังรูปภาพส่วนกลาง แต่ด้วยการใช้เทคนิคเฉพาะของบริการ พวกเขาจึงสามารถเพิ่มประสิทธิภาพได้ ผลผลิตของตัวเอง(เช่น การขอคิว หรือการแคชรูปภาพยอดนิยม - มีรายละเอียดเพิ่มเติมในภายหลัง) จากทั้งมุมมองของบริการและต้นทุน แต่ละบริการสามารถปรับขนาดได้อย่างอิสระตามต้องการ และนี่เป็นสิ่งที่ดี เนื่องจากการรวมและการผสมอาจส่งผลต่อประสิทธิภาพการทำงานโดยไม่ได้ตั้งใจ ดังในสถานการณ์ที่อธิบายไว้ข้างต้น

แน่นอนว่าโมเดลข้างต้นจะทำงานได้อย่างเหมาะสมหากมีจุดสิ้นสุดที่แตกต่างกันสองจุด (อันที่จริงนี่คล้ายกับการใช้งานผู้ให้บริการพื้นที่เก็บข้อมูลบนคลาวด์และเครือข่ายการจัดส่งเนื้อหาหลายรายการ) มีวิธีแก้ปัญหามากมาย ปัญหาที่คล้ายกันและในแต่ละกรณีสามารถพบการประนีประนอมได้

ตัวอย่างเช่น Flickr แก้ปัญหาการอ่าน-เขียนนี้โดยการกระจายผู้ใช้ไปยังพ็อดต่างๆ เพื่อให้แต่ละพ็อดสามารถให้บริการผู้ใช้เฉพาะในจำนวนที่จำกัดเท่านั้น และเมื่อจำนวนผู้ใช้เพิ่มขึ้น พ็อดต่างๆ จะถูกเพิ่มเข้าไปในคลัสเตอร์มากขึ้น (ดูการนำเสนอการปรับขนาดของ Flickr ,
http://mysqldba.blogspot.com/2008/04/mysql-uc-2007-presentation-file.html) ในตัวอย่างแรก จะง่ายกว่าในการปรับขนาดฮาร์ดแวร์ตามปริมาณการใช้งานจริง (จำนวนการอ่านและเขียนในทั้งระบบ) ในขณะที่ Flickr จะปรับขนาดตามฐานผู้ใช้ (อย่างไรก็ตาม การดำเนินการนี้จะใช้สมมติฐานของการใช้งานที่เท่ากันทั่วทั้งระบบ) ผู้ใช้ที่แตกต่างกัน ดังนั้นจึงต้องวางแผนกำลังการผลิตตามสต็อก) ในอดีต ความไม่พร้อมใช้งานหรือปัญหากับบริการใดบริการหนึ่งอาจทำให้ฟังก์ชันการทำงานเสียหาย ทั้งระบบ(เช่นไม่มีใครสามารถเขียนไฟล์ได้) ดังนั้นความไม่พร้อมใช้งานของหนึ่งในโมดูล Flickr จะส่งผลกระทบต่อผู้ใช้ที่เกี่ยวข้องเท่านั้น ในตัวอย่างแรก การดำเนินการกับชุดข้อมูลทั้งหมดทำได้ง่ายกว่า เช่น การอัปเดตบริการการบันทึกเพื่อรวมข้อมูลเมตาใหม่ หรือการค้นหาข้อมูลเมตาของรูปภาพทั้งหมด ในขณะที่สถาปัตยกรรม Flickr แต่ละโมดูลจะต้องได้รับการอัปเดตหรือค้นหา ( หรือต้องสร้างบริการค้นหาเพื่อจัดเรียงข้อมูลเมตาที่มีไว้สำหรับจุดประสงค์นี้จริงๆ)

สำหรับระบบเหล่านี้ ไม่มียาครอบจักรวาล แต่คุณควรดำเนินการตามหลักการที่อธิบายไว้ในตอนต้นของบทนี้เสมอ: กำหนดความต้องการของระบบ (โหลดการอ่านหรือเขียนหรือทั้งสองอย่าง ระดับของความขนาน การสืบค้นชุดข้อมูล ช่วง การเรียงลำดับ ฯลฯ) ดำเนินการทดสอบเกณฑ์มาตรฐานเปรียบเทียบของทางเลือกต่างๆ ทำความเข้าใจสภาวะความล้มเหลวของระบบที่อาจเกิดขึ้น และพัฒนาแผนงานที่ครอบคลุมหากเกิดความล้มเหลว

ความซ้ำซ้อน

เพื่อจัดการกับความล้มเหลวอย่างสวยงาม สถาปัตยกรรมเว็บจะต้องมีความซ้ำซ้อนในบริการและข้อมูล ตัวอย่างเช่น หากมีสำเนาไฟล์เพียงชุดเดียวที่จัดเก็บไว้ในเซิร์ฟเวอร์เดียว การสูญเสียเซิร์ฟเวอร์นั้นจะหมายถึงการสูญเสียไฟล์ นี่ไม่น่าจะเป็นสถานการณ์เชิงบวก และโดยปกติสามารถหลีกเลี่ยงได้โดยการสร้างสำเนาหรือการสำรองข้อมูลหลายชุด

หลักการเดียวกันนี้ใช้กับบริการ คุณสามารถป้องกันความล้มเหลวของโหนดเดียวได้โดยการมอบส่วนสำคัญของฟังก์ชันการทำงานสำหรับแอปพลิเคชันที่รับประกัน ทำงานพร้อมกันมีสำเนาหรือเวอร์ชันหลายชุด

การสร้างความซ้ำซ้อนในระบบช่วยให้คุณกำจัดจุดอ่อนและจัดให้มีฟังก์ชันการสำรองข้อมูลหรือซ้ำซ้อนในกรณีฉุกเฉิน ตัวอย่างเช่น หากมีอินสแตนซ์สองอินสแตนซ์ของบริการเดียวกันที่ทำงานอยู่ในการใช้งานจริง และหนึ่งในนั้นล้มเหลวทั้งหมดหรือบางส่วน ระบบสามารถเอาชนะความล้มเหลวได้โดย เปลี่ยนเป็นสำเนาการทำงาน.
การสลับอาจเกิดขึ้นโดยอัตโนมัติหรือต้องมีการแทรกแซงด้วยตนเอง

.

บทบาทสำคัญอีกประการหนึ่งของบริการซ้ำซ้อนคือการสร้าง สถาปัตยกรรมที่ไม่มีการแบ่งปันทรัพยากร. ด้วยสถาปัตยกรรมนี้ แต่ละโหนดสามารถทำงานได้อย่างอิสระ และยิ่งไปกว่านั้น ในกรณีที่ไม่มี "สมอง" ส่วนกลางที่จัดการสถานะหรือประสานงานการดำเนินการของโหนดอื่นๆ ส่งเสริมความสามารถในการปรับขนาดเนื่องจากการเพิ่มโหนดใหม่ไม่จำเป็นต้องมีเงื่อนไขหรือความรู้พิเศษ สิ่งสำคัญที่สุดคือ ระบบเหล่านี้ไม่มีจุดวิกฤตของความล้มเหลว ทำให้ทนทานต่อความล้มเหลวได้มากขึ้น

.

ตัวอย่างเช่น ในแอปพลิเคชันเซิร์ฟเวอร์รูปภาพของเรา รูปภาพทั้งหมดจะมีสำเนาซ้ำซ้อนในฮาร์ดแวร์อีกชิ้นหนึ่ง (ตามหลักการแล้วในตำแหน่งทางภูมิศาสตร์ที่แตกต่างกันในกรณีที่เกิดภัยพิบัติ เช่น แผ่นดินไหวหรือไฟไหม้ในศูนย์ข้อมูล) และบริการต่างๆ การเข้าถึงรูปภาพจะซ้ำซ้อน เนื่องจากรูปภาพทั้งหมดอาจตอบสนองคำขอได้ (ซม. .)
เมื่อมองไปข้างหน้า ตัวจัดสรรภาระงานเป็นวิธีที่ดีเยี่ยมในการทำให้สิ่งนี้เป็นไปได้ แต่มีข้อมูลเพิ่มเติมอยู่ด้านล่าง

รูปที่ 1.3: แอปพลิเคชันโฮสต์รูปภาพซ้ำซ้อน

การแบ่งส่วน

ชุดข้อมูลอาจมีขนาดใหญ่จนไม่สามารถจัดวางบนเซิร์ฟเวอร์เครื่องเดียวได้ นอกจากนี้ยังอาจเกิดขึ้นได้ว่าการดำเนินการด้านคอมพิวเตอร์ต้องใช้ทรัพยากรคอมพิวเตอร์มากเกินไป ทำให้ประสิทธิภาพลดลงและจำเป็นต้องใช้พลังงานเพิ่มขึ้น ไม่ว่าในกรณีใด คุณมีสองตัวเลือก: มาตราส่วนแนวตั้งหรือแนวนอน

การปรับสเกลแนวตั้งเกี่ยวข้องกับการเพิ่มทรัพยากรเพิ่มเติมให้กับเซิร์ฟเวอร์เดียว ดังนั้น สำหรับชุดข้อมูลที่มีขนาดใหญ่มาก นี่อาจหมายถึงการเพิ่มฮาร์ดไดรฟ์มากขึ้น (หรือใหญ่กว่า) เพื่อให้ชุดข้อมูลทั้งหมดสามารถใส่ได้บนเซิร์ฟเวอร์เดียว ในกรณีของการดำเนินการคำนวณ นี่หมายถึงการย้ายการคำนวณไปยังเซิร์ฟเวอร์ขนาดใหญ่ที่มี CPU ที่เร็วกว่าหรือมีหน่วยความจำมากกว่า ไม่ว่าในกรณีใด การปรับสเกลแนวตั้งจะดำเนินการเพื่อทำให้ทรัพยากรระบบคอมพิวเตอร์เดียวสามารถประมวลผลข้อมูลเพิ่มเติมได้

ในทางกลับกัน การปรับสเกลแนวนอนเกี่ยวข้องกับการเพิ่มโหนดเพิ่มเติม ในกรณีของชุดข้อมูลขนาดใหญ่ นี่อาจหมายถึงการเพิ่มเซิร์ฟเวอร์ตัวที่สองเพื่อจัดเก็บส่วนหนึ่งของปริมาณข้อมูลทั้งหมด และสำหรับทรัพยากรการประมวลผล นี่จะหมายถึงการแบ่งงานหรือโหลดข้ามโหนดเพิ่มเติมบางโหนด เพื่อใช้ประโยชน์สูงสุดจากศักยภาพ มาตราส่วนแนวนอนก็จะต้องมีการดำเนินการเป็น หลักการภายในการพัฒนาสถาปัตยกรรมระบบ มิฉะนั้น การเปลี่ยนแปลงและการแยกบริบทที่จำเป็นสำหรับการปรับสเกลแนวนอนอาจเป็นปัญหาได้

วิธีการขยายแนวนอนที่พบบ่อยที่สุดคือการแบ่งบริการออกเป็นส่วนๆ หรือโมดูล สามารถกระจายในลักษณะที่ชุดฟังก์ชันเชิงตรรกะแต่ละชุดทำงานแยกกัน ซึ่งสามารถทำได้ตามขอบเขตทางภูมิศาสตร์ หรือเกณฑ์อื่นๆ เช่น ผู้ใช้ที่ชำระเงินและไม่ชำระเงิน ข้อดีของโครงร่างเหล่านี้คือให้บริการหรือที่เก็บข้อมูลพร้อมฟังก์ชันที่ได้รับการปรับปรุง

ในตัวอย่างเซิร์ฟเวอร์รูปภาพของเรา อาจเป็นไปได้ว่าเซิร์ฟเวอร์ไฟล์เดียวที่ใช้จัดเก็บรูปภาพอาจถูกแทนที่ด้วยเซิร์ฟเวอร์ไฟล์หลายเครื่อง โดยแต่ละไฟล์มีชุดรูปภาพเฉพาะของตัวเอง (ดู) สถาปัตยกรรมนี้จะอนุญาตให้ระบบเติมอิมเมจลงในเซิร์ฟเวอร์ไฟล์แต่ละไฟล์ โดยเพิ่มเซิร์ฟเวอร์เพิ่มเติมเมื่อเต็ม พื้นที่ดิสก์. การออกแบบจะต้องมีรูปแบบการตั้งชื่อที่เชื่อมโยงชื่อของไฟล์รูปภาพกับเซิร์ฟเวอร์ที่มีอยู่ ชื่อรูปภาพสามารถสร้างขึ้นได้จากรูปแบบการแฮชที่สอดคล้องกันซึ่งเชื่อมโยงกับเซิร์ฟเวอร์ หรืออีกทางหนึ่ง รูปภาพแต่ละรูปอาจมี ID ส่วนเพิ่ม ซึ่งจะทำให้บริการจัดส่งสามารถประมวลผลเฉพาะช่วงของ ID ที่เกี่ยวข้องกับเซิร์ฟเวอร์แต่ละเครื่องเท่านั้น (เป็นดัชนี) เมื่อทำการร้องขอรูปภาพ

รูปที่ 1.4: แอปพลิเคชันโฮสต์รูปภาพที่มีความซ้ำซ้อนและการแบ่งส่วน

แน่นอนว่าการแจกจ่ายข้อมูลหรือฟังก์ชันการทำงานไปยังเซิร์ฟเวอร์ต่างๆ ย่อมประสบความยากลำบาก หนึ่งในคำถามสำคัญก็คือ ตำแหน่งข้อมูล; ในระบบแบบกระจาย ยิ่งข้อมูลอยู่ใกล้จุดดำเนินการหรือการคำนวณมากเท่าใด ประสิทธิภาพที่ดีขึ้นระบบ ด้วยเหตุนี้ การกระจายข้อมูลไปยังเซิร์ฟเวอร์หลายเครื่องอาจเป็นปัญหาได้ เนื่องจากอาจจำเป็นต้องใช้ข้อมูลในเวลาใดก็ตาม มีความเสี่ยงที่ข้อมูลอาจไม่พร้อมใช้งานในตำแหน่งที่ต้องการ เซิร์ฟเวอร์จะต้องดำเนินการดึงข้อมูลที่จำเป็นซึ่งมีค่าใช้จ่ายสูง เครือข่าย.

ปัญหาที่อาจเกิดขึ้นอีกประการหนึ่งเกิดขึ้นในแบบฟอร์ม
ความไม่สอดคล้องกัน (ความไม่สอดคล้องกัน)เมื่อบริการต่างๆ อ่านและเขียนไปยังทรัพยากรที่ใช้ร่วมกัน ซึ่งอาจเป็นบริการหรือที่เก็บข้อมูลอื่น ก็เป็นไปได้ที่ "สภาวะการแข่งขัน" จะเกิดขึ้น - โดยที่ข้อมูลบางส่วนคิดว่าจะได้รับการอัปเดตเป็นสถานะล่าสุด แต่จริงๆ แล้วจะถูกอ่านก่อน อัปเดต - ในกรณีนี้ข้อมูลไม่สอดคล้องกัน ตัวอย่างเช่น ในสถานการณ์การโฮสต์รูปภาพ สภาพการแข่งขันอาจเกิดขึ้นหากไคลเอนต์รายหนึ่งส่งคำขอให้อัปเดตรูปภาพของสุนัข โดยเปลี่ยนชื่อ "Dog" เป็น "Gizmo" ในขณะที่ไคลเอนต์อื่นกำลังอ่านรูปภาพ ในสถานการณ์เช่นนี้ ยังไม่ชัดเจนว่าลูกค้ารายที่สองจะได้รับชื่อ "Dog" หรือ "Gizmo"

.

แน่นอนว่ามีอุปสรรคบางประการที่เกี่ยวข้องกับการแบ่งส่วนข้อมูล แต่การแบ่งส่วนทำให้คุณสามารถแยกแต่ละปัญหาออกจากปัญหาอื่นๆ ได้ เช่น ตามข้อมูล ตามปริมาณงาน ตามรูปแบบการใช้งาน ฯลฯ เข้าสู่บล็อกที่ได้รับการจัดการ สิ่งนี้สามารถช่วยในเรื่องความสามารถในการปรับขนาดและการจัดการ แต่ก็ยังมีความเสี่ยงอยู่ มีหลายวิธีในการลดความเสี่ยงและจัดการกับความล้มเหลว อย่างไรก็ตาม เพื่อความกระชับ จึงไม่ครอบคลุมเนื้อหาเหล่านี้ในบทนี้ หากคุณต้องการข้อมูลเพิ่มเติมเกี่ยวกับหัวข้อนี้ คุณควรดูที่โพสต์บนบล็อกเกี่ยวกับการยอมรับข้อบกพร่องและการตรวจสอบ

1.3. Building Block สำหรับการเข้าถึงข้อมูลที่รวดเร็วและปรับขนาดได้

เมื่อดูหลักการพื้นฐานบางประการในการพัฒนาระบบแบบกระจายแล้ว ตอนนี้เรามาดูปัญหาที่ซับซ้อนมากขึ้นกันดีกว่า นั่นก็คือ การขยายขนาดการเข้าถึงข้อมูล

เว็บแอปพลิเคชันที่ง่ายที่สุด เช่น แอปพลิเคชัน LAMP stack จะคล้ายกับรูปภาพใน .

รูปที่ 1.5: เว็บแอปพลิเคชันแบบธรรมดา

เมื่อแอปพลิเคชันเติบโตขึ้น ความท้าทายหลักสองประการก็เกิดขึ้น: การขยายขนาดการเข้าถึงเซิร์ฟเวอร์แอปพลิเคชันและฐานข้อมูล ในการออกแบบแอปพลิเคชันที่ปรับขนาดได้สูง โดยทั่วไปเว็บหรือเซิร์ฟเวอร์แอปพลิเคชันจะถูกย่อให้เล็กสุดและมักใช้สถาปัตยกรรมการแบ่งปันทรัพยากร ซึ่งทำให้เลเยอร์แอปพลิเคชันเซิร์ฟเวอร์ของระบบสามารถปรับขนาดในแนวนอนได้ จากการออกแบบนี้ การยกของหนักจะเปลี่ยนสแต็กลงไปยังเซิร์ฟเวอร์ฐานข้อมูลและบริการสนับสนุน เลเยอร์นี้เป็นจุดที่ปัญหาการปรับขนาดและประสิทธิภาพที่แท้จริงเข้ามามีบทบาท

ส่วนที่เหลือของบทนี้ครอบคลุมถึงกลยุทธ์และเทคนิคทั่วไปบางประการในการปรับปรุงประสิทธิภาพและความสามารถในการปรับขนาดของบริการประเภทนี้โดยให้การเข้าถึงข้อมูลที่รวดเร็ว

รูปที่ 1.6: เว็บแอปพลิเคชันแบบง่าย

ระบบส่วนใหญ่สามารถทำให้ง่ายขึ้นเป็นวงจรเข้า
ซึ่งเป็นจุดที่ดีในการเริ่มค้นหา หากคุณมีข้อมูลจำนวนมาก ก็ปลอดภัยที่จะสมมติว่าคุณต้องการให้เข้าถึงได้ง่ายและรวดเร็วเหมือนกับกล่องขนมในลิ้นชักบนโต๊ะของคุณ แม้ว่า การเปรียบเทียบนี้พูดง่ายเกินไป มันชี้ไปที่สอง ปัญหาที่ซับซ้อน: ความสามารถในการปรับขนาดการจัดเก็บข้อมูลและการเข้าถึงข้อมูลที่รวดเร็ว

สำหรับวัตถุประสงค์ของส่วนนี้ สมมติว่าคุณมีข้อมูลหลายเทราไบต์ (TB) และคุณอนุญาตให้ผู้ใช้เข้าถึงข้อมูลส่วนเล็กๆ ตามลำดับแบบสุ่ม (ซม. .)
งานที่คล้ายกันคือการกำหนดตำแหน่งของไฟล์รูปภาพที่ใดที่หนึ่ง ไฟล์เซิร์ฟเวอร์ในแอปพลิเคชันโฮสต์รูปภาพตัวอย่าง

รูปที่ 1.7: การเข้าถึงข้อมูลเฉพาะ

นี่เป็นเรื่องยากเป็นพิเศษเนื่องจากการโหลดข้อมูลเทราไบต์ลงในหน่วยความจำอาจมีราคาแพงมากและส่งผลโดยตรงต่อ I/O ของดิสก์ ความเร็วในการอ่านจากดิสก์นั้นต่ำกว่าความเร็วในการอ่านหลายเท่า หน่วยความจำเข้าถึงโดยสุ่ม- คุณอาจพูดได้ว่าการเข้าถึงหน่วยความจำนั้นเร็วเท่ากับ Chuck Norris ในขณะที่การเข้าถึงดิสก์นั้นช้ากว่าคิวที่คลินิก ความแตกต่างของความเร็วนี้เห็นได้ชัดเจนโดยเฉพาะสำหรับชุดข้อมูลขนาดใหญ่ ในตัวเลขดิบ การเข้าถึงหน่วยความจำจะเร็วกว่าการอ่านดิสก์ 6 เท่าสำหรับการอ่านตามลำดับ และเร็วกว่า 100,000 เท่าสำหรับการอ่านแบบสุ่ม (ดู Pathologies of Big Data, http://queue.acm.org/detail. cfm?id=1563874) ). ยิ่งไปกว่านั้น แม้ว่าจะมีตัวระบุที่ไม่ซ้ำกัน การแก้ปัญหาในการค้นหาข้อมูลชิ้นเล็กๆ ก็อาจทำได้ยากพอๆ กับการพยายามหยิบลูกอมที่เต็มไปด้วยช็อกโกแลตชิ้นสุดท้ายจากกล่องที่มีลูกอมอื่นๆ หลายร้อยชิ้นโดยไม่ต้องมอง

โชคดีที่มีหลายวิธีที่สามารถนำไปใช้เพื่อลดความซับซ้อน โดยมีสี่วิธีที่สำคัญที่สุดคือการใช้แคช พร็อกซี ดัชนี และโหลดบาลานเซอร์ ส่วนที่เหลือของส่วนนี้จะกล่าวถึงวิธีการใช้แต่ละแนวคิดเหล่านี้เพื่อทำให้การเข้าถึงข้อมูลเร็วขึ้นมาก

แคช

การแคชจะได้รับประโยชน์จากคุณลักษณะของหลักการพื้นฐาน: ข้อมูลที่ร้องขอล่าสุดมีแนวโน้มที่จะต้องการอีกครั้ง แคชถูกใช้ในการประมวลผลเกือบทุกระดับ: ฮาร์ดแวร์ ระบบปฏิบัติการ เว็บเบราว์เซอร์ เว็บแอปพลิเคชัน และอื่นๆ แคชเปรียบเสมือนหน่วยความจำระยะสั้น: มีขนาดจำกัด แต่เร็วกว่าแหล่งข้อมูลดั้งเดิมและมีรายการต่างๆ ที่เพิ่งเข้าถึง แคชสามารถมีอยู่ในทุกระดับในสถาปัตยกรรม แต่มักจะพบในระดับที่ใกล้กับส่วนหน้ามากที่สุด โดยจะมีการนำไปใช้เพื่อส่งคืนข้อมูลอย่างรวดเร็วโดยไม่ต้องโหลดแบ็กเอนด์ที่มีนัยสำคัญ

แล้วแคชสามารถใช้เพื่อเร่งความเร็วการเข้าถึงข้อมูลภายใน API ตัวอย่างของเราได้อย่างไร ในกรณีนี้ มีตำแหน่งแคชที่เหมาะสมหลายแห่ง ตัวเลือกตำแหน่งหนึ่งที่เป็นไปได้คือการเลือกโหนดในระดับการสืบค้น ดังที่แสดงใน
.

รูปที่ 1.8: ตำแหน่งแคชบนโหนดระดับแบบสอบถาม

การวางแคชโดยตรงบนโหนดระดับคำขอช่วยให้สามารถจัดเก็บข้อมูลการตอบสนองในเครื่องได้ แต่ละครั้งที่มีการร้องขอบริการ โหนดจะส่งคืนข้อมูลที่แคชในเครื่องอย่างรวดเร็ว ถ้ามี หากไม่อยู่ในแคช โหนดคำขอจะขอข้อมูลจากดิสก์ แคชบนโหนดระดับการสืบค้นหนึ่งสามารถวางได้ทั้งในหน่วยความจำ (ซึ่งเร็วมาก) และเปิดอยู่ ดิสก์ภายในเครื่องโหนด (เร็วกว่าการพยายามเข้าถึงที่เก็บข้อมูลเครือข่าย)

รูปภาพ 1.9: ระบบแคช

จะเกิดอะไรขึ้นเมื่อคุณกระจายแคชไปยังหลาย ๆ โหนด อย่างที่คุณเห็น หากระดับคำขอมีหลายโหนด ก็มีแนวโน้มว่าแต่ละโหนดจะมีแคชของตัวเอง อย่างไรก็ตาม หากโหลดบาลานเซอร์ของคุณสุ่มกระจายคำขอไปยังโหนดต่างๆ คำขอเดียวกันนั้นจะถูกส่งไปยังโหนดที่แตกต่างกัน ซึ่งจะทำให้แคชหายไปมากขึ้น สองวิธีในการเอาชนะอุปสรรคนี้คือแคชส่วนกลางและแคชแบบกระจาย

แคชทั่วโลก

ความหมายของแคชส่วนกลางนั้นชัดเจนจากชื่อ: โหนดทั้งหมดใช้พื้นที่แคชเดียวร่วมกัน ในกรณีนี้ คุณเพิ่มเซิร์ฟเวอร์หรือพื้นที่จัดเก็บไฟล์บางประเภทที่เร็วกว่าพื้นที่จัดเก็บเดิมของคุณ และจะพร้อมใช้งานสำหรับโหนดระดับคำขอทั้งหมด แต่ละโหนดคำขอจะสอบถามแคชในลักษณะเดียวกับว่าเป็นแคชในเครื่อง รูปแบบการแคชประเภทนี้อาจทำให้เกิดปัญหาบางประการได้ เนื่องจากแคชเดี่ยวสามารถโอเวอร์โหลดได้ง่ายมากหากจำนวนไคลเอ็นต์และคำขอเพิ่มขึ้น ในเวลาเดียวกัน รูปแบบนี้มีประสิทธิภาพมากกับสถาปัตยกรรมบางอย่าง (โดยเฉพาะอย่างยิ่งสถาปัตยกรรมที่เกี่ยวข้องกับฮาร์ดแวร์พิเศษที่ทำให้แคชส่วนกลางนี้เร็วมาก หรือที่มีชุดข้อมูลคงที่ที่ต้องแคช)

มีสอง รูปร่างมาตรฐานแคชส่วนกลางที่แสดงในไดอะแกรม สถานการณ์ที่แสดงคือเมื่อไม่พบการตอบสนองที่แคชไว้ในแคช ตัวแคชเองก็มีหน้าที่ในการดึงข้อมูลที่ขาดหายไปจากที่จัดเก็บข้อมูลพื้นฐาน ภาพประกอบเป็นความรับผิดชอบของโหนดคำขอในการดึงข้อมูลใดๆ ที่ไม่พบในแคช

รูปที่ 1.10: แคชส่วนกลาง โดยที่แคชมีหน้าที่ในการดึงข้อมูล

รูปภาพ 1.11: แคชส่วนกลาง โดยที่โหนดคำขอมีหน้าที่รับผิดชอบในการดึงข้อมูล

แอปพลิเคชันส่วนใหญ่ที่ใช้ประโยชน์จากแคชส่วนกลางมักจะใช้ประเภทแรก โดยที่แคชจะจัดการการแทนที่และดึงข้อมูลเพื่อป้องกันไม่ให้ไคลเอนต์ส่งคำขอข้อมูลเดียวกันอย่างท่วมท้น อย่างไรก็ตาม มีบางกรณีที่การใช้งานครั้งที่สองมีความเหมาะสมมากกว่า ตัวอย่างเช่น หากใช้แคชสำหรับไฟล์ที่มีขนาดใหญ่มาก อัตราการเข้าถึงแคชที่ต่ำจะทำให้แคชบัฟเฟอร์โอเวอร์โหลดโดยที่แคชหายไป ในสถานการณ์นี้ การมีเปอร์เซ็นต์จำนวนมากของชุดข้อมูลทั้งหมด (หรือชุดข้อมูลที่ร้อนแรง) ในแคช อีกตัวอย่างหนึ่งคือสถาปัตยกรรมที่ไฟล์ที่จัดเก็บไว้ในแคชเป็นแบบคงที่และไม่ควรถูกลบ (ซึ่งอาจเกิดขึ้นเนื่องจากคุณลักษณะด้านประสิทธิภาพพื้นฐานที่เกี่ยวข้องกับเวลาแฝงของข้อมูลดังกล่าว - บางทีบางส่วนของข้อมูลจำเป็นต้องเร็วมากสำหรับชุดข้อมูลขนาดใหญ่ - โดยที่ตรรกะของแอปพลิเคชันเข้าใจกลยุทธ์การแทนที่หรือฮอตสปอตได้ดีกว่าแคช)

แคชแบบกระจาย

ดัชนีเหล่านี้มักถูกจัดเก็บไว้ในหน่วยความจำหรือที่ใดที่หนึ่งภายในคำขอไคลเอ็นต์ที่เข้ามา Berkeley DB (BDB) และโครงสร้างข้อมูลแบบต้นไม้ ซึ่งโดยทั่วไปจะใช้เพื่อจัดเก็บข้อมูลตามลำดับรายการ เหมาะอย่างยิ่งสำหรับการเข้าถึงแบบจัดทำดัชนี

มักจะมีดัชนีหลายชั้นที่ทำหน้าที่เป็นแผนที่ ย้ายคุณจากที่หนึ่งไปยังอีกที่หนึ่ง และอื่นๆ จนกว่าคุณจะได้ชิ้นส่วนข้อมูลที่คุณต้องการ (ซม.)

รูปที่ 1.17: ดัชนีหลายระดับ

ดัชนียังใช้เพื่อสร้างมุมมองอื่นๆ ของข้อมูลเดียวกันได้หลายมุมมอง สำหรับชุดข้อมูลขนาดใหญ่ นี่เป็นวิธีที่ดีในการกำหนดตัวกรองและมุมมองต่างๆ โดยไม่ต้องสร้างจำนวนมาก สำเนาเพิ่มเติมข้อมูล.

ตัวอย่างเช่น สมมติว่าระบบโฮสต์รูปภาพที่กล่าวถึงข้างต้นโฮสต์รูปภาพหน้าหนังสือจริง ๆ และบริการนี้อนุญาตให้ลูกค้าค้นหาข้อความในภาพเหล่านั้น ค้นหาเนื้อหาข้อความทั้งหมดในหัวข้อที่ระบุในลักษณะเดียวกับที่เครื่องมือค้นหาอนุญาต เพื่อค้นหาเนื้อหา HTML ในกรณีนี้ รูปภาพหนังสือทั้งหมดใช้เซิร์ฟเวอร์จำนวนมากในการจัดเก็บไฟล์ และการค้นหาหน้าเดียวเพื่อนำเสนอต่อผู้ใช้อาจเป็นเรื่องยากทีเดียว ในขั้นต้น ดัชนีย้อนกลับสำหรับการสืบค้นคำและชุดคำที่กำหนดเองควรจะพร้อมใช้งาน จึงมีภารกิจเลื่อนไปยังหน้าและตำแหน่งที่แน่นอนในหนังสือเล่มนั้นและดึงข้อมูลกลับมา ภาพที่ถูกต้องสำหรับผลการค้นหา ดังนั้นในกรณีนี้ ดัชนีกลับหัวจะแมปไปยังตำแหน่ง (เช่น เล่ม B) จากนั้น B อาจมีดัชนีพร้อมคำ ตำแหน่ง และจำนวนทั้งหมดที่เกิดขึ้นในแต่ละส่วน

ดัชนีกลับหัว ซึ่ง Index1 อาจแสดงในแผนภาพด้านบน จะมีลักษณะดังนี้: แต่ละคำหรือชุดคำทำหน้าที่เป็นดัชนีสำหรับหนังสือเหล่านั้นที่มีคำหรือชุดคำเหล่านั้น

ดัชนีระดับกลางจะมีลักษณะคล้ายกัน แต่จะมีเพียงคำ ตำแหน่ง และข้อมูลของหนังสือ B สถาปัตยกรรมแบบเลเยอร์นี้ทำให้แต่ละดัชนีใช้พื้นที่น้อยกว่าถ้าข้อมูลทั้งหมดนี้ถูกจัดเก็บไว้ในดัชนีกลับหัวขนาดใหญ่เพียงดัชนีเดียว

และนี่คือจุดสำคัญในระบบขนาดใหญ่ เนื่องจากแม้ในขณะที่ถูกบีบอัด ดัชนีเหล่านี้ก็อาจมีขนาดค่อนข้างใหญ่และมีราคาแพงในการจัดเก็บ สมมติว่าเรามีหนังสือหลายเล่มจากทั่วโลกในระบบนี้ - 100,000,000 เล่ม (ดูโพสต์ในบล็อก "Inside Google Books") - และหนังสือแต่ละเล่มมีความยาวเพียง 10 หน้า (เพื่อให้การคำนวณง่ายขึ้น) โดยมี 250 คำต่อหน้า : ซึ่งจะช่วยให้ เรามีทั้งหมด 250 พันล้านคำ หากเรานำจำนวนอักขระโดยเฉลี่ยในคำหนึ่งๆ เป็น 5 และเข้ารหัสอักขระแต่ละตัวด้วย 8 บิต (หรือ 1 ไบต์ แม้ว่าอักขระบางตัวจะใช้พื้นที่จริงถึง 2 ไบต์ก็ตาม) จึงใช้จ่าย 5 ไบต์ต่อคำ ดังนั้นดัชนีที่ประกอบด้วยอักขระแต่ละตัว word เพียงครั้งเดียวจะต้องมีการจัดเก็บข้อมูลมากกว่า 1 เทราไบต์ ดังนั้นคุณจะเห็นได้ว่าดัชนีที่มีข้อมูลอื่นๆ เช่น ชุดคำ ตำแหน่งข้อมูล และจำนวนการใช้งาน สามารถขยายขนาดได้อย่างรวดเร็ว

การสร้างดัชนีระดับกลางและการนำเสนอข้อมูลเป็นชิ้นเล็กๆ ทำให้ปัญหาข้อมูลขนาดใหญ่แก้ไขได้ง่ายขึ้น ข้อมูลสามารถกระจายไปยังเซิร์ฟเวอร์หลายเครื่องและสามารถเข้าถึงได้อย่างรวดเร็วในเวลาเดียวกัน ดัชนีเป็นรากฐานที่สำคัญของการเรียกค้นข้อมูลและเป็นพื้นฐานสำหรับเครื่องมือค้นหาสมัยใหม่ในปัจจุบัน แน่นอนว่าส่วนนี้เป็นเพียงเนื้อหาคร่าวๆ ของหัวข้อการจัดทำดัชนีเท่านั้น และมีการวิจัยมากมายเกี่ยวกับวิธีทำให้ดัชนีมีขนาดเล็กลง เร็วขึ้น มีข้อมูลเพิ่มเติม (เช่น ความเกี่ยวข้อง) และอัปเดตได้ง่าย (มีปัญหาบางประการเกี่ยวกับการจัดการเงื่อนไขการแข่งขัน รวมถึงจำนวนการอัปเดตที่จำเป็นในการเพิ่มข้อมูลใหม่หรือเปลี่ยนแปลงข้อมูลที่มีอยู่ โดยเฉพาะอย่างยิ่งเมื่อเกี่ยวข้องกับความเกี่ยวข้องหรือการให้คะแนน)

ความสามารถในการค้นหาข้อมูลของคุณอย่างรวดเร็วและง่ายดายเป็นสิ่งสำคัญ และดัชนีเป็นเครื่องมือที่ง่ายและมีประสิทธิภาพมากที่สุดในการบรรลุเป้าหมายนี้

โหลดบาลานเซอร์

สุดท้าย ส่วนสำคัญอีกประการหนึ่งของระบบแบบกระจายก็คือโหลดบาลานเซอร์ ตัวจัดสรรภาระงานเป็นส่วนสำคัญของสถาปัตยกรรมใดๆ เนื่องจากบทบาทของพวกเขาคือการกระจายโหลดไปยังโหนดที่รับผิดชอบในการให้บริการคำขอ ซึ่งช่วยให้หลายโหนดสามารถให้บริการฟังก์ชันเดียวกันในระบบได้อย่างโปร่งใส (ดู) วัตถุประสงค์หลักของพวกเขาคือการจัดการการเชื่อมต่อพร้อมกันจำนวนมากและกำหนดเส้นทางการเชื่อมต่อเหล่านั้นไปยังหนึ่งในโหนดที่ร้องขอ ทำให้ระบบสามารถปรับขนาดได้โดยเพียงแค่เพิ่มโหนดที่จะให้บริการ ปริมาณมากคำขอ

รูปภาพ 1.18: โหลดบาลานเซอร์

มีมากมาย อัลกอริธึมต่างๆเพื่อให้บริการตามคำขอ รวมถึงการเลือกโหนดแบบสุ่ม การวนรอบ หรือแม้แต่การเลือกโหนดตามเกณฑ์ที่กำหนด เช่น การใช้งาน โปรเซสเซอร์กลางหรือแรม โหลดบาลานเซอร์สามารถใช้เป็นอุปกรณ์ฮาร์ดแวร์หรือซอฟต์แวร์ได้ ในบรรดาโหลดบาลานเซอร์ซอฟต์แวร์โอเพ่นซอร์ส HAProxy ถูกใช้อย่างแพร่หลายที่สุด

ในระบบแบบกระจาย โหลดบาลานเซอร์มักจะอยู่ที่ "ส่วนหน้า" ของระบบ เพื่อให้คำขอที่เข้ามาทั้งหมดส่งผ่านโดยตรง มีความเป็นไปได้มากว่าในระบบแบบกระจายที่ซับซ้อน คำขอจะต้องผ่านบาลานเซอร์หลายตัว ดังที่แสดงใน
.

รูปภาพ 1.19: โหลดบาลานเซอร์หลายตัว

เช่นเดียวกับพร็อกซี ตัวจัดสรรภาระงานบางตัวสามารถกำหนดเส้นทางคำขอที่แตกต่างกันออกไป โดยขึ้นอยู่กับประเภทของคำขอ พวกเขายังเป็นที่รู้จักกันในนามผู้รับมอบฉันทะแบบย้อนกลับ

การจัดการข้อมูลเฉพาะสำหรับเซสชันผู้ใช้โดยเฉพาะถือเป็นความท้าทายประการหนึ่งเมื่อใช้โหลดบาลานเซอร์ บนไซต์อีคอมเมิร์ซ เมื่อคุณมีลูกค้าเพียงรายเดียว จะเป็นเรื่องง่ายมากที่จะอนุญาตให้ผู้ใช้วางสินค้าในรถเข็นและบันทึกเนื้อหาระหว่างการเข้าชม (นี่เป็นสิ่งสำคัญเนื่องจากแนวโน้มที่จะขายสินค้าเพิ่มขึ้นอย่างมากหากเมื่อผู้ใช้ กลับมาที่ไซต์แล้ว สินค้ายังอยู่ในตะกร้าสินค้า) อย่างไรก็ตาม หากผู้ใช้ถูกนำทางไปยังโหนดหนึ่งสำหรับเซสชันแรก จากนั้นไปยังโหนดอื่นในการเข้าชมครั้งถัดไป ความไม่สม่ำเสมออาจเกิดขึ้นได้เนื่องจากโหนดใหม่อาจไม่มีความรู้เกี่ยวกับเนื้อหาในรถเข็นช็อปปิ้งของผู้ใช้นั้น (คุณจะไม่เสียใจหรือถ้าคุณใส่แพ็คเกจ Mountain Dew ไว้ในรถเข็นแล้วกลับมาไม่มีเลย) วิธีแก้ปัญหาหนึ่งอาจเป็นการทำให้เซสชัน "ติดหนึบ" เพื่อให้ผู้ใช้ถูกนำทางไปยังโหนดเดียวกันเสมอ อย่างไรก็ตาม การใช้ประโยชน์จากคุณลักษณะความน่าเชื่อถือบางอย่าง เช่น การเฟลโอเวอร์อัตโนมัติ จะเป็นเรื่องยากมาก ในกรณีนี้ รถเข็นของผู้ใช้จะมีเนื้อหาอยู่เสมอ แต่หาก Sticky Node ไม่สามารถเข้าถึงได้ ก็จำเป็นต้องมีแนวทางพิเศษ และสมมติฐานเกี่ยวกับเนื้อหาของรถเข็นจะไม่เป็นจริงอีกต่อไป (แต่หวังว่าสมมติฐานนี้จะไม่ถูกสร้างขึ้นใน ใบสมัคร) แน่นอนว่าปัญหานี้สามารถแก้ไขได้โดยใช้กลยุทธ์และเครื่องมืออื่นๆ เช่น ที่อธิบายไว้ในบทนี้ เช่น บริการ และอื่นๆ อีกมากมาย (เช่น แคชของเบราว์เซอร์ คุกกี้ และการเขียน URL ใหม่)

หากระบบมีโหนดเพียงไม่กี่โหนด เทคนิคต่างๆ เช่น DNS carousel น่าจะใช้งานได้จริงมากกว่าโหลดบาลานเซอร์ ซึ่งอาจมีราคาแพงและเพิ่มความซับซ้อนที่ไม่จำเป็นให้กับระบบ แน่นอนใน ระบบขนาดใหญ่มีอัลกอริธึมการตั้งเวลาและการทำโหลดบาลานซ์ที่แตกต่างกันทุกประเภท รวมถึงอัลกอริธึมง่ายๆ ด้วย การเลือกแบบสุ่มหรืออัลกอริธึมแบบหมุนหรือมากกว่า กลไกที่ซับซ้อนโดยคำนึงถึงคุณสมบัติด้านประสิทธิภาพของรูปแบบการใช้งานของระบบ อัลกอริธึมทั้งหมดนี้ช่วยให้สามารถกระจายการรับส่งข้อมูลและคำขอได้ และสามารถให้เครื่องมือที่เชื่อถือได้ที่เป็นประโยชน์ เช่น ความทนทานต่อข้อผิดพลาดโดยอัตโนมัติ หรือการลบโหนดที่ล้มเหลวโดยอัตโนมัติ (เช่น เมื่อหยุดตอบสนองต่อคำขอ) อย่างไรก็ตาม คุณสมบัติขั้นสูงเหล่านี้อาจทำให้การวินิจฉัยปัญหายุ่งยากได้ ตัวอย่างเช่น ในสถานการณ์ที่มีโหลดสูง โหลดบาลานเซอร์จะลบโหนดที่อาจทำงานช้าหรือหมดเวลา (เนื่องจากมีคำขอจำนวนมาก) ซึ่งมีแต่จะทำให้สิ่งต่าง ๆ แย่ลงสำหรับโหนดอื่น ๆ การตรวจสอบอย่างครอบคลุมเป็นสิ่งสำคัญในกรณีเหล่านี้ เนื่องจากแม้ว่าการรับส่งข้อมูลและโหลดของระบบโดยรวมจะลดลง (เนื่องจากโหนดให้บริการคำขอน้อยลง) - แต่ละโหนดอาจจะโหลดได้ถึงขีดจำกัด

โหลดบาลานเซอร์เป็นวิธีง่ายๆ ในการเพิ่มความจุของระบบ เช่นเดียวกับวิธีการอื่นๆ ที่อธิบายไว้ในบทความนี้ มีบทบาทสำคัญในสถาปัตยกรรมระบบแบบกระจาย โหลดบาลานเซอร์ยังมีฟังก์ชันที่สำคัญในการตรวจสอบความสมบูรณ์ของโหนดอีกด้วย จากการตรวจสอบดังกล่าว หากโหนดไม่ตอบสนองหรือโอเวอร์โหลด ก็สามารถลบออกจากพูลการประมวลผลคำขอได้ และด้วยความซ้ำซ้อนของระบบของคุณ โหลดจะถูกแจกจ่ายซ้ำไปยังโหนดทำงานที่เหลือ .

คิว

จนถึงตอนนี้เราได้ดูวิธีการต่างๆ มากมายในการอ่านข้อมูลอย่างรวดเร็ว ในขณะเดียวกัน อีกส่วนสำคัญในการปรับขนาดชั้นข้อมูลก็คือการจัดการบันทึกที่มีประสิทธิภาพ เมื่อระบบเรียบง่ายและมีโหลดการประมวลผลน้อยที่สุดและมีฐานข้อมูลขนาดเล็ก การเขียนจึงสามารถคาดเดาได้รวดเร็ว อย่างไรก็ตาม ในระบบที่ซับซ้อนมากขึ้น กระบวนการนี้อาจใช้เวลานานอย่างไม่มีกำหนด ตัวอย่างเช่น ข้อมูลอาจต้องเขียนลงในหลายตำแหน่งบนเซิร์ฟเวอร์หรือดัชนีที่แตกต่างกัน หรือระบบอาจมีภาระงานสูง ในกรณีที่การเขียน หรือแม้แต่งานใดๆ ก็ตาม ใช้เวลานาน การบรรลุประสิทธิภาพและความพร้อมใช้งานจำเป็นต้องสร้างอะซิงโครนัสเข้าสู่ระบบ วิธีทั่วไปในการทำเช่นนี้คือการจัดระเบียบคิวคำขอ

รูปที่ 1.20: คำขอแบบซิงโครนัส

ลองนึกภาพระบบที่ลูกค้าแต่ละรายร้องของาน การบำรุงรักษาระยะไกล. ไคลเอนต์เหล่านี้แต่ละรายส่งคำขอไปยังเซิร์ฟเวอร์ ซึ่งทำงานโดยเร็วที่สุดและส่งผลลัพธ์ไปยังไคลเอนต์ที่เกี่ยวข้อง ในระบบขนาดเล็กที่เซิร์ฟเวอร์เดียว (หรือบริการแบบลอจิคัล) สามารถให้บริการไคลเอ็นต์ขาเข้าได้อย่างรวดเร็วเมื่อมาถึง สถานการณ์ในลักษณะนี้ควรจะทำงานได้ดี อย่างไรก็ตาม เมื่อเซิร์ฟเวอร์ได้รับคำขอมากกว่าที่จะจัดการได้ ไคลเอ็นต์แต่ละรายจะถูกบังคับให้รอให้คำขอของไคลเอ็นต์อื่นดำเนินการให้เสร็จสิ้นก่อนที่จะสร้างการตอบสนองต่อคำขอของตนเอง นี่คือตัวอย่างของคำขอแบบซิงโครนัส ซึ่งแสดงในรูปแบบ .

ลักษณะการทำงานแบบซิงโครนัสประเภทนี้สามารถลดประสิทธิภาพของไคลเอนต์ได้อย่างมาก ในความเป็นจริง เนื่องจากไม่ได้ใช้งาน ลูกค้าจึงถูกบังคับให้รอจนกว่าจะได้รับการตอบกลับต่อคำขอ การเพิ่มเซิร์ฟเวอร์เพิ่มเติมเพื่อรับมือกับโหลดของระบบไม่สามารถแก้ปัญหาได้จริง แม้ว่าจะมีการปรับสมดุลโหลดอย่างมีประสิทธิภาพแล้วก็ตาม ก็ยังเป็นเรื่องยากมากที่จะจัดให้มีการกระจายโหลดที่สม่ำเสมอและยุติธรรมซึ่งจำเป็นเพื่อเพิ่มผลผลิตของลูกค้าให้สูงสุด นอกจากนี้ หากเซิร์ฟเวอร์ที่ใช้ประมวลผลคำขอนี้ไม่พร้อมใช้งาน (หรือขัดข้อง) ไคลเอ็นต์ที่เชื่อมต่อกับเซิร์ฟเวอร์ก็จะหยุดทำงานเช่นกัน วิธีแก้ปัญหาที่มีประสิทธิผลสำหรับปัญหานี้จำเป็นต้องมีสิ่งที่เป็นนามธรรมระหว่างคำขอของลูกค้ากับงานจริงที่ดำเนินการเพื่อให้บริการ

รูปที่ 1.21: การใช้คิวเพื่อจัดการคำขอ

คิวเข้า. วิธีการทำงานของคิวนั้นง่ายมาก: งานมาถึง เข้าคิว จากนั้น “พนักงาน” จะยอมรับงานถัดไปทันทีที่มีโอกาสประมวลผล (ดู) งานเหล่านี้อาจเป็นรายการฐานข้อมูลธรรมดาหรืองานที่ซับซ้อนพอๆ กับการสร้างรูปภาพ ดูตัวอย่างสำหรับเอกสาร เมื่อไคลเอนต์ส่งคำของานไปยังคิว ก็ไม่จำเป็นต้องรอผลการดำเนินการอีกต่อไป คำขอเพียงต้องการการยืนยันว่าได้รับอย่างถูกต้องเท่านั้น การยืนยันนี้สามารถใช้เป็นข้อมูลอ้างอิงถึงผลงานได้ในภายหลังเมื่อลูกค้าร้องขอ

คิวอนุญาตให้ไคลเอ็นต์ทำงานในลักษณะอะซิงโครนัส โดยให้นามธรรมเชิงกลยุทธ์ของคำขอและการตอบสนองของลูกค้า ในทางกลับกัน ในระบบซิงโครนัส ไม่มีความแตกต่างระหว่างคำขอและการตอบสนอง ดังนั้นจึงไม่สามารถจัดการแยกกันได้ ในระบบอะซิงโครนัส ไคลเอนต์ส่งงาน บริการตอบกลับด้วยข้อความยืนยันว่าได้รับงานแล้ว และไคลเอนต์สามารถตรวจสอบสถานะของงานเป็นระยะ ๆ โดยขอผลลัพธ์เมื่อเสร็จสิ้นเท่านั้น ในขณะที่ไคลเอนต์กำลังส่งคำขอแบบอะซิงโครนัส คุณสามารถทำงานอื่นได้ฟรี และแม้แต่ส่งคำขอแบบอะซิงโครนัสจากบริการอื่น ๆ ก็ได้ อย่างหลังเป็นตัวอย่างของวิธีการทำงานของคิวและข้อความในระบบแบบกระจาย

คิวยังช่วยป้องกันการหยุดชะงักและความล้มเหลวของบริการอีกด้วย ตัวอย่างเช่น มันค่อนข้างง่ายที่จะสร้างคิวที่ยืดหยุ่นมากซึ่งสามารถลองคำขอบริการที่ล้มเหลวเนื่องจากเซิร์ฟเวอร์ขัดข้องชั่วขณะได้ ควรใช้คิวเพื่อบังคับใช้การรับประกันคุณภาพของบริการ แทนที่จะปล่อยให้ลูกค้าพบกับบริการหยุดชะงักชั่วคราว ซึ่งต้องมีการจัดการข้อผิดพลาดที่ซับซ้อนและมักจะไม่สอดคล้องกันในฝั่งไคลเอ็นต์

คิวเป็นหลักการพื้นฐานในการจัดการการส่งข้อมูลแบบกระจายระหว่างส่วนต่างๆ ของระบบแบบกระจายขนาดใหญ่ และมีหลายวิธีในการนำไปใช้ มีการใช้งานคิวโอเพ่นซอร์สค่อนข้างน้อยเช่น RabbitMQ
ActiveMQ
BeanstalkD แต่บางอันก็ใช้บริการเช่น

การปรับขนาด

คอมพิวเตอร์แบบกระจาย

การพัฒนาเว็บ

เคท มัตสึไดระ

เพิ่มแท็ก

การออกแบบบนพื้นฐานของเทคโนโลยีบริการเว็บ

ความชำนาญพิเศษ: 05.13.12 – การออกแบบระบบอัตโนมัติ

เซนต์ปีเตอร์สเบิร์ก 2013 2

งานนี้ดำเนินการที่สถาบันการศึกษางบประมาณระดับอุดมศึกษาของรัฐบาลกลาง อาชีวศึกษา"มหาวิทยาลัยเทคนิคไฟฟ้าแห่งรัฐเซนต์ปีเตอร์สเบิร์ก "LETI" ตั้งชื่อตาม V. I. Ulyanova (เลนิน) ภาควิชาระบบการออกแบบโดยใช้คอมพิวเตอร์ช่วย

ผู้อำนวยการด้านวิทยาศาสตร์– วิทยาศาสตรดุษฎีบัณฑิต สาขาเทคนิคศาสตร์ ศาสตราจารย์ ดมิเทรวิช เกนนาดี ดานีโลวิช

ฝ่ายตรงข้ามอย่างเป็นทางการ:

วิทยาศาสตรดุษฎีบัณฑิต, ศาสตราจารย์, มหาวิทยาลัยเทคนิคไฟฟ้าแห่งรัฐเซนต์ปีเตอร์สเบิร์ก "LETI" ตั้งชื่อตาม ในและ

Ulyanova (เลนิน) กรมประมวลผลข้อมูลอัตโนมัติและระบบควบคุม Kutuzov Oleg Ivanovich ผู้สมัครสาขาวิทยาศาสตร์เทคนิค บริษัท ร่วมทุนเปิด "ข้อกังวล"

"สมาคมวิจัยและการผลิต "ออโรรา"

หัวหน้าห้องปฏิบัติการ Pakhomenkov Yury Mikhailovich

องค์กรชั้นนำ: สถาบันการศึกษางบประมาณของรัฐบาลกลางด้านการศึกษาวิชาชีพระดับสูง "มหาวิทยาลัยวิจัยเทคโนโลยีสารสนเทศกลศาสตร์และทัศนศาสตร์แห่งเซนต์ปีเตอร์สเบิร์ก"

การป้องกันวิทยานิพนธ์จะมีขึ้นในวันที่ 23 พฤษภาคม 2556 เวลา 16.30 น. ในการประชุมของสภาวิทยานิพนธ์ D212.238.02 ของมหาวิทยาลัยเทคนิคไฟฟ้าแห่งรัฐเซนต์ปีเตอร์สเบิร์ก "LETI" ซึ่งตั้งชื่อตาม ในและ

Ulyanova (เลนิน) ตามที่อยู่: 197376, เซนต์ปีเตอร์สเบิร์ก, เซนต์ ศาสตราจารย์โปโปวา, 5.

วิทยานิพนธ์สามารถพบได้ในห้องสมุดของมหาวิทยาลัยเทคนิคอิเล็กทรอนิกส์แห่งรัฐเซนต์ปีเตอร์สเบิร์ก บทคัดย่อถูกส่งไป “_” 2013

เลขาธิการสภาวิทยานิพนธ์ D212.238.02 N. M. Safyannikov

คำอธิบายทั่วไปของงาน

ความเกี่ยวข้องการวิจัย การนำระบบการออกแบบโดยใช้คอมพิวเตอร์ช่วยมาใช้อย่างกว้างขวางในการแก้ไขปัญหาทางวิศวกรรมนั้นมีจำกัดอย่างมาก ค่าใช้จ่ายที่สูงซอฟต์แวร์ลิขสิทธิ์ นอกจากนี้ การสร้างระบบ CAD ของคุณเองยังเกี่ยวข้องกับการใช้ทรัพยากรจำนวนมาก และไม่สามารถทำได้ในระยะเวลาอันสั้น เนื่องจากการพัฒนาระบบ CAD สมัยใหม่ต้องใช้แรงงานหลายร้อยปี ปัญหายังซับซ้อนด้วยความจริงที่ว่าในสถานการณ์การทำงานจริงนั้น ตามกฎแล้วระบบ CAD แบบบูรณาการแบบมัลติฟังก์ชั่นนั้นไม่ได้ผลอย่างมากเนื่องจากเมื่อทำการแก้ไข งานเฉพาะจากองค์ประกอบหลักของระบบเหล่านี้ มักจะใช้ซอฟต์แวร์ที่เฉพาะเจาะจงที่สุดสำหรับแต่ละแผนกไม่เกิน 10-20%

วิธีแก้ปัญหาเร่งด่วนนี้อาจเป็นการกระจายอำนาจของสถาปัตยกรรม CAD ผ่านการเปลี่ยนไปใช้ระบบการออกแบบแบบกระจายที่สร้างขึ้นบนพื้นฐานของเทคโนโลยีอินเทอร์เน็ตที่ใช้ งานการสื่อสารและ การแลกเปลี่ยนข้อมูลระหว่างแอปพลิเคชัน

แอปพลิเคชันที่ได้รับการจัดการอย่างอิสระเหล่านี้ทำงานอัตโนมัติและสามารถสื่อสารระหว่างกันเพื่อทำงานทั่วไปให้สำเร็จได้

โปรโตคอลเทคโนโลยีอินเทอร์เน็ตเป็นพื้นฐานที่เชื่อถือได้สำหรับการเชื่อมโยงระบบย่อย และไม่จำเป็นต้องใช้ทรัพยากรร่วมกันซึ่งอยู่ในโหนดเครือข่ายที่แตกต่างกัน ซึ่งช่วยให้กระบวนการสร้างและใช้งานระบบ CAD แบบกระจายง่ายขึ้นอย่างมาก ข้อกำหนดหลักสำหรับความเป็นไปได้ในการใช้งานระบบแบบกระจายคือความสอดคล้องของอินเทอร์เฟซที่แต่ละระบบย่อยเชื่อมต่อกัน เมื่อเป็นไปตามข้อกำหนดนี้ ส่วนประกอบแต่ละส่วนสามารถสร้าง CAD แบบกระจายได้ โดยนักพัฒนาต่างๆและเก็บรักษาไว้ในไซต์ต่างๆ ที่จะจัดส่ง (อาจเป็นเชิงพาณิชย์) ไปยังผู้บริโภค

วิธีการที่มีประสิทธิภาพมากที่สุดในการรวมระบบย่อยเข้ากับแอปพลิเคชันแบบกระจายควรได้รับการพิจารณาว่าเป็นองค์กรของการเรียกขั้นตอนระยะไกลตามสถาปัตยกรรมเชิงบริการโดยใช้บริการเว็บ บูรณาการตามบริการเว็บในการพัฒนาระบบ CAD แบบกระจายอำนาจช่วยให้คุณสามารถไปยังคำอธิบายของอินเทอร์เฟซและการโต้ตอบตาม XML โดยให้ความสามารถในการแก้ไขและพัฒนาซอฟต์แวร์ที่สร้างขึ้นในขณะที่ยังคงรักษาอินเทอร์เฟซที่เลือกไว้ เนื่องจากการมีเพศสัมพันธ์ที่หลวมของระบบย่อยแต่ละระบบ ช่วยให้มั่นใจได้ถึงการมีปฏิสัมพันธ์ระหว่างบริการบนแพลตฟอร์มที่กำหนดเอง และเพื่อปรับแอปพลิเคชันที่มีอยู่ให้เข้ากับเงื่อนไขการออกแบบที่เปลี่ยนแปลงไป

ภาระหลักของการดำเนินการคำนวณด้วยสถาปัตยกรรมดังกล่าวตกอยู่ที่บริการบนเว็บที่แก้ไขปัญหาทั้งหมดของการสร้างแบบจำลองระบบที่ได้รับการออกแบบ แอปพลิเคชันไคลเอนต์จะได้รับมอบหมายเฉพาะฟังก์ชันที่ง่ายที่สุดในการเตรียมข้อมูลและแสดงผลการสร้างแบบจำลอง เมื่อพัฒนา CAD โดยใช้บริการบนเว็บ สามารถใช้ประเภทต่อไปนี้ได้ แอปพลิเคชันไคลเอนต์:

แอปพลิเคชันประเภทคอนโซล แอปพลิเคชันประเภทหน้าต่าง และแอปพลิเคชันเว็บ

คุณลักษณะของแอปพลิเคชันคอนโซลคือการไม่มีอินเทอร์เฟซแบบกราฟิก แต่การใช้งานจะมีประโยชน์เมื่อใช้ระบบ CAD แบบง่ายสำหรับพ็อกเก็ตคอมพิวเตอร์ที่มีพื้นที่หน้าจอขนาดเล็ก

แอปพลิเคชันแบบหน้าต่างทำให้สามารถนำไปใช้งานได้ดีที่สุด เครื่องมือกราฟิกและเหมาะที่สุดสำหรับการพัฒนาระบบแบบกระจายตามบริการบนเว็บ สำหรับบริการเว็บใดๆ คุณสามารถสร้างแอปพลิเคชันไคลเอนต์หลายตัวด้วยวิธีการโต้ตอบโต้ตอบที่แตกต่างกัน

เว็บแอปพลิเคชันช่วยให้สามารถวางซอฟต์แวร์ CAD ทั้งหมดของคุณทางออนไลน์ได้ทั้งหมด ข้อดีของการนำโครงสร้างนี้ไปใช้ก็คือ เปิดการเข้าถึงหากต้องการใช้ CAD แบบกระจายผ่านเบราว์เซอร์ทุกประเภท ข้อเสียของแอปพลิเคชันประเภทนี้คือต้องใช้เวลาเพิ่มขึ้นในการอธิบายส่วนประกอบของระบบที่ออกแบบเนื่องจากการรอการตอบสนองในขั้นตอนการป้อนข้อมูลแต่ละรายการ

สำหรับแอปพลิเคชันไคลเอนต์ทุกประเภท บริการทางเว็บจะถูกเรียกใช้ในลักษณะเดียวกัน และสำหรับแต่ละบริการบนเว็บ คุณสามารถใช้วิธีใดก็ได้เพื่อใช้งานแอปพลิเคชันไคลเอนต์ที่เขียนด้วยภาษาที่แตกต่างกัน หากจำเป็น แอปพลิเคชันไคลเอนต์ดังกล่าวสามารถปรับเปลี่ยนได้อย่างง่ายดายเพื่อให้เหมาะกับเงื่อนไขการออกแบบที่เปลี่ยนแปลงไป และยังสามารถขยายบริการเว็บเพื่อรวมวิธีการเพิ่มเติมได้อีกด้วย

เป้าหมายของการทำงานและวัตถุประสงค์หลักของการวิจัย วิทยานิพนธ์นี้อุทิศให้กับการวิจัยและพัฒนาวิธีการสร้างระบบ CAD แบบกระจายที่ไม่ขึ้นกับแพลตฟอร์มโดยใช้บริการเว็บ สำหรับการใช้งานเฉพาะได้เลือกงานในการพัฒนาระบบอัตโนมัติแบบกระจายสำหรับการออกแบบวงจร

เพื่อให้บรรลุเป้าหมายนี้ ควรแก้ไขงานต่อไปนี้:

1. พัฒนาวิธีการทั่วไปสำหรับการสร้าง การทดสอบออฟไลน์ และการปรับใช้กับเซิร์ฟเวอร์บริการเว็บ Java ที่เลือก

ซอฟต์แวร์บริการเว็บ Java สำหรับระบบอัตโนมัติการออกแบบวงจรแบบกระจาย

3. วิจัยและพัฒนาวิธีการสำหรับการสร้างบริการเว็บ Java โดยใช้เทคโนโลยีการบีบอัดข้อมูล

4. ดำเนินการวิจัยและพัฒนาวิธีการทั่วไปสำหรับการสร้างเทมเพลตสำหรับแอปพลิเคชันไคลเอนต์ประเภทคอนโซลและหน้าต่าง รวมถึงเว็บแอปพลิเคชันไคลเอนต์

5. พัฒนาวิธีการสำหรับการนำการทำงานของบริการเว็บและแอปพลิเคชันไคลเอนต์ไปใช้ในสภาพแวดล้อมที่ต่างกัน

วิธีการวิจัย ในการปฏิบัติงานที่ได้รับมอบหมายในวิทยานิพนธ์จะใช้พื้นฐาน ทฤษฎีทั่วไป CAD ทฤษฎีระบบการสร้างแบบจำลอง ทฤษฎีพื้นฐานของเมทริกซ์และกราฟ

ความน่าเชื่อถือของผลลัพธ์ทางวิทยาศาสตร์ได้รับการยืนยันโดยบทบัญญัติพื้นฐานของทฤษฎีทั่วไปของ CAD ทฤษฎีการสร้างแบบจำลอง ความถูกต้องของอุปกรณ์ทางคณิตศาสตร์ที่ใช้ และผลลัพธ์ที่ได้จากการทดสอบซอฟต์แวร์ที่สร้างขึ้นสำหรับบริการเว็บและแอปพลิเคชันไคลเอนต์

ผลลัพธ์ทางวิทยาศาสตร์ใหม่ของ CAD แบบกระจายโดยใช้บริการบนเว็บ

2. วิธีการทั่วไปได้รับการพัฒนาสำหรับการใช้งาน การทดสอบออฟไลน์ และการปรับใช้บริการเว็บ Java บนเซิร์ฟเวอร์ CAD แบบกระจาย

3. วิจัยและพัฒนาวิธีการสร้างซอฟต์แวร์บริการเว็บ Java เพื่อแก้ไขปัญหาการออกแบบวงจรอิเล็กทรอนิกส์ทั่วไป

5. วิธีการทั่วไปสำหรับการสร้างแอปพลิเคชันไคลเอนต์คอนโซลและหน้าต่าง รวมถึงเว็บแอปพลิเคชันไคลเอนต์ได้รับการพัฒนาแล้ว

6. วิธีการได้รับการพัฒนาสำหรับการนำซอฟต์แวร์ CAD แบบกระจายไปใช้สำหรับการจัดระเบียบการโต้ตอบในสภาพแวดล้อมที่แตกต่างกันของบริการเว็บและแอปพลิเคชันไคลเอนต์

บทบัญญัติพื้นฐาน 1. สถาปัตยกรรมของ CAD ที่มุ่งเน้นบริการแบบกระจายโดยอิงจากบริการบนเว็บ

2. วิธีการทั่วไปสำหรับการออกแบบบริการเว็บ Java จากล่างขึ้นบน 3. วิธีการสำหรับการนำซอฟต์แวร์บริการเว็บ Java ไปใช้โดยอาศัยการบีบอัดข้อมูล

คุณค่าทางปฏิบัติ 1. โครงสร้าง CAD แบบกระจายที่เสนอให้ความสามารถในการจัดระเบียบการโต้ตอบระหว่างบริการเว็บต่างๆ บนแพลตฟอร์มที่เลือก และปรับแอปพลิเคชันให้เข้ากับเงื่อนไขการออกแบบที่เปลี่ยนแปลง

2. ไลบรารีฟังก์ชันเสริมที่สร้างขึ้นโดยอิงจากการบีบอัดข้อมูลจะช่วยเพิ่มประสิทธิภาพในการสร้างซอฟต์แวร์บริการเว็บ Java สำหรับระบบอัตโนมัติในการออกแบบวงจร 3. วิธีการที่พัฒนาขึ้นสำหรับการใช้การโต้ตอบระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ช่วยให้มั่นใจถึงการทำงานของระบบ CAD แบบกระจายในสภาพแวดล้อมที่แตกต่างกัน

4. ซอฟต์แวร์ของระบบอัตโนมัติแบบกระจายที่พัฒนาขึ้นสำหรับการออกแบบวงจรประกอบด้วยเคอร์เนลที่ไม่แปรผันสำหรับการจัดขั้นตอนทั้งเชิงสัญลักษณ์และตัวเลขของโปรแกรม Java ซึ่งสามารถใช้เป็นพื้นฐานสำหรับระบบการออกแบบการสร้างสำหรับวัตถุที่หลากหลาย

การดำเนินการและการดำเนินการตามผลลัพธ์ ระบบ CAD แบบกระจายที่พัฒนาขึ้นในวิทยานิพนธ์โดยใช้บริการเว็บถูกนำมาใช้ใน Java โดยใช้แพลตฟอร์ม WTP (แพลตฟอร์มเครื่องมือเว็บ) ผลลัพธ์ในทางปฏิบัติคือระบบ CAD การออกแบบวงจรแบบกระจายที่ไม่ขึ้นอยู่กับแพลตฟอร์ม ซึ่งดำเนินการการสร้างแบบจำลองหลายตัวแปรของวงจรไม่เชิงเส้นในโหมดคงที่ ในโหมดไดนามิก สำหรับการคำนวณ ลักษณะความถี่และยังให้การคำนวณความไวของฟังก์ชันการถ่ายโอนและความไวของตัวแปรสถานะคงตัวต่อการแปรผันของพารามิเตอร์

ผลวิทยานิพนธ์ถูกนำมาใช้ในการวิจัยงบประมาณของรัฐในหัวข้อ “การพัฒนาแบบจำลองและวิธีการวิเคราะห์และสังเคราะห์ ระบบอัจฉริยะการสนับสนุนการตัดสินใจสำหรับการจัดการวัตถุกระจายที่ซับซ้อน" (แผนวิชารหัส CAD-47 ของ St. Petersburg Electrotechnical University 2011) และในหัวข้อ "รากฐานทางคณิตศาสตร์และตรรกะของการสร้างสภาพแวดล้อมเครื่องมือเสมือน" (รหัสแผนวิชา CAD-49 SPbGETU 2012) ผลวิทยานิพนธ์ นำเข้าสู่การปฏิบัติงานด้านวิศวกรรมของบริษัทผลิตทางวิทยาศาสตร์ "Modem" และใช้ในกระบวนการศึกษาของแผนก CAD ของมหาวิทยาลัยเทคนิคแห่งรัฐเซนต์ปีเตอร์สเบิร์ก เพื่อศึกษาวิธีการสร้างซอฟต์แวร์สำหรับระบบอัตโนมัติของการออกแบบวงจรในการเตรียมความพร้อมในระดับปริญญาตรีและปริญญาโท ในสาขา "วิศวกรรมสารสนเทศและคอมพิวเตอร์"

การอนุมัติงานบทบัญญัติหลักของวิทยานิพนธ์ได้รับการรายงานและอภิปรายในการประชุมต่อไปนี้:

1. การประชุมนักวิทยาศาสตร์รุ่นเยาว์ครั้งที่ 9 เรื่อง “การนำทางและการควบคุมการจราจร” – เซนต์ปีเตอร์สเบิร์ก

2. การประชุมนานาชาติครั้งที่ 5 “การสร้างเครื่องมือในระบบนิเวศและความปลอดภัยของมนุษย์” – เซนต์ปีเตอร์สเบิร์ก, SUAI;

3. สิบสาม สิบสี่ สิบเจ็ด การประชุมระดับนานาชาติ“การศึกษาสมัยใหม่ เนื้อหา เทคโนโลยี คุณภาพ” – เซนต์ปีเตอร์สเบิร์ก, 4. 60, 61, การประชุมทางวิทยาศาสตร์และเทคนิคครั้งที่ 63 ของอาจารย์ SETU

สิ่งพิมพ์เนื้อหาทางทฤษฎีและการปฏิบัติหลักของวิทยานิพนธ์นี้ได้รับการตีพิมพ์ในผลงานทางวิทยาศาสตร์ 16 ชิ้น รวมถึงบทความ 4 ชิ้นในสิ่งพิมพ์ที่ผ่านการตรวจสอบโดยผู้ทรงคุณวุฒิชั้นนำที่แนะนำอยู่ในรายชื่อคณะกรรมการรับรองที่สูงขึ้นในปัจจุบัน ใบรับรอง 1 ใบ การลงทะเบียนอย่างเป็นทางการโปรแกรมคอมพิวเตอร์ที่ลงทะเบียนกับ Federal Service สำหรับทรัพย์สินทางปัญญา สิทธิบัตร และเครื่องหมายการค้า

โครงสร้างและขอบเขตของวิทยานิพนธ์วิทยานิพนธ์ประกอบด้วยคำนำ เนื้อหาหลัก 4 บท บทสรุป และบรรณานุกรมที่มีแหล่งข้อมูล 69 แหล่ง งานนี้นำเสนอด้วยข้อความ 154 หน้า มีตัวเลข 21 ตัว และตาราง 1 ตาราง

ในการแนะนำตัวมีการให้เหตุผลสำหรับความเกี่ยวข้องของหัวข้อวิทยานิพนธ์ มีการกำหนดวัตถุประสงค์ของการวิจัย และให้รายการงานที่ต้องแก้ไขในงาน

ในบทแรกมีการพิจารณาประเด็นของการสร้างสถาปัตยกรรมของแอปพลิเคชันแบบกระจาย ซึ่งกำหนดโครงสร้างทั่วไป ฟังก์ชันที่ดำเนินการ และความสัมพันธ์ของแต่ละส่วนประกอบของระบบ

แสดงให้เห็นว่าสถาปัตยกรรมของแอปพลิเคชันแบบกระจายครอบคลุมทั้งด้านโครงสร้างและพฤติกรรม ตลอดจนกฎของการบูรณาการและการใช้งาน ฟังก์ชันการทำงาน ความยืดหยุ่น ความน่าเชื่อถือ ประสิทธิภาพ การใช้ซ้ำ ข้อจำกัดทางเทคโนโลยี และปัญหาอินเทอร์เฟซผู้ใช้ วัตถุประสงค์หลักของการรวมแอปพลิเคชันอัตโนมัติ (ระบบย่อย) เข้ากับแอปพลิเคชันแบบกระจายคือเพื่อให้การเชื่อมต่อการทำงานที่ให้การโต้ตอบที่จำเป็นโดยมีการพึ่งพาน้อยที่สุดระหว่างระบบย่อย

งานวิทยานิพนธ์แสดงให้เห็นว่ากลไกดังกล่าวได้รับการจัดเตรียมอย่างมีประสิทธิภาพสูงสุดเมื่อใช้สถาปัตยกรรมตามปฏิสัมพันธ์ระหว่างระบบย่อยโดยใช้การเรียกขั้นตอนระยะไกล ใช้สำหรับการแลกเปลี่ยนข้อมูล และสำหรับการดำเนินการบางอย่าง ในกรณีที่แอปพลิเคชันจำเป็นต้องดึงหรือเปลี่ยนแปลงข้อมูลใด ๆ ที่แอปพลิเคชันอื่นเก็บไว้ จะเข้าถึงผ่านการเรียกใช้ฟังก์ชัน

ในการสร้างระบบ CAD แบบกระจาย วิทยานิพนธ์เสนอให้ใช้สถาปัตยกรรมเชิงบริการ (SOA) ตามโครงสร้างซอฟต์แวร์แบบโมดูลาร์และอินเทอร์เฟซมาตรฐาน SOA ใช้การรวมกระบวนการปฏิบัติงานขั้นพื้นฐาน หลักการของการใช้องค์ประกอบการทำงานซ้ำๆ และการจัดระเบียบตามแพลตฟอร์มบูรณาการ แม้ว่าสถาปัตยกรรม SOA จะไม่เกี่ยวข้องกับเทคโนโลยีการเรียกขั้นตอนระยะไกลใดๆ โดยเฉพาะ แต่ระบบย่อยซอฟต์แวร์ที่ออกแบบตาม SOA มักจะถูกนำมาใช้เป็นชุดของบริการเว็บที่เชื่อมโยงโดยใช้โปรโตคอลพื้นฐาน (SOAP, WSDL)

ระบบที่ใช้สถาปัตยกรรมเชิงบริการจัดอยู่ในกลุ่มของระบบหลายเอเจนต์ (MAS) ซึ่งถูกสร้างขึ้นโดยเอเจนต์อัจฉริยะที่มีการโต้ตอบหลายตัว ซึ่งรับประกันความเป็นอิสระ การเป็นตัวแทนที่จำกัด และการกระจายอำนาจของระบบย่อยแต่ละระบบของระบบคอมพิวเตอร์ข้อมูลแบบกระจาย

บริการทางเว็บเป็นไปตามมาตรฐาน XML และช่วยให้ผู้ใช้โต้ตอบกับเครื่องมือระบบภายนอกผ่านทางอินเทอร์เน็ต ซึ่งเป็นส่วนประกอบคู่อย่างหลวมๆ ของระบบซอฟต์แวร์ที่พร้อมใช้งานผ่านอินเทอร์เน็ตโปรโตคอล งานวิทยานิพนธ์แสดงให้เห็นว่าในการใช้งานจริงของระบบ CAD แบบกระจายโดยใช้บริการบนเว็บ ควรให้ความสนใจอย่างมากกับการแบ่งหน้าที่รับผิดชอบที่ถูกต้องซึ่งกำหนดให้กับแอปพลิเคชันไคลเอนต์หลักและบริการเว็บที่โต้ตอบกับแอปพลิเคชันนี้

วิธีการเฉพาะสำหรับการใช้บริการเว็บนั้นขึ้นอยู่กับภาษาการเขียนโปรแกรมที่เลือกเป็นอย่างมาก งานแสดงให้เห็นว่าการตั้งค่าเมื่อเลือกภาษาการเขียนโปรแกรมสำหรับการสร้างบริการเว็บควรให้กับภาษา Java ซึ่งช่วยให้มั่นใจได้ถึงความเป็นอิสระของแพลตฟอร์มของโซลูชันที่นำไปใช้อย่างเต็มที่ ปัจจัยสำคัญที่สนับสนุนตัวเลือกนี้ก็คือความพร้อมของการสนับสนุนเครื่องมือที่มีประสิทธิภาพสำหรับการพัฒนาแอปพลิเคชันบนเว็บใน Java ซึ่งจัดทำโดยสภาพแวดล้อม WTP (แพลตฟอร์มเครื่องมือเว็บ)

งานวิทยานิพนธ์ดำเนินการวิเคราะห์เปรียบเทียบของสองวิธีหลักในการสร้างบริการเว็บ Java - จากล่างขึ้นบน (จากล่างขึ้นบน) เมื่อสร้างคลาส Java ของบริการเว็บเป็นครั้งแรกจากนั้นเอกสาร WSDL จะถูกสร้างขึ้นตามนั้น และจากบนลงล่าง (จากบนลงล่าง) เมื่อเอกสาร WSDL ที่จำเป็นถูกสร้างขึ้นครั้งแรก จากนั้นโค้ดการใช้งานบริการเว็บจะถูกสร้างขึ้นตามเอกสารดังกล่าว จากการประเมินเชิงเปรียบเทียบ แสดงให้เห็นว่าการออกแบบบริการเว็บควรดำเนินการโดยใช้วิธีจากล่างขึ้นบน เนื่องจากในกรณีนี้ เอกสาร WSDL จะถูกสร้างขึ้นตามคลาส Java ที่สร้างขึ้นล่วงหน้า ซึ่งอธิบายพารามิเตอร์ทั้งหมดที่ส่งไปยัง วิธีการบริการเว็บและค่าที่ส่งคืนโดยวิธีนี้ ในกรณีนี้ ข้อมูลทั้งหมดที่มีอยู่ในคลาส Java จะถูกแปลงเป็นเอกสาร WSDL ที่เกี่ยวข้องโดยอัตโนมัติ เนื้อหาที่สอดคล้องกับโครงสร้างพื้นฐานของข้อกำหนด WSDL และคุณสมบัติหลักของวิธีการบริการเว็บที่เรียกว่า ซึ่งช่วยให้มั่นใจว่าสมบูรณ์ ความน่าเชื่อถือของข้อมูลที่มีอยู่ในเอกสาร WSDL

เพื่อให้สามารถนำการออกแบบบริการเว็บไปใช้ในทางปฏิบัติโดยใช้วิธีจากล่างขึ้นบน วิทยานิพนธ์เสนอวิธีการสำหรับการสร้างโครงการเว็บแบบไดนามิกและคลาส Java สำหรับการใช้บริการเว็บที่มีอยู่ในนั้นพร้อมคำอธิบายของวิธีการที่เรียกว่า ซึ่งนอกเหนือจากวิธีการทำงานหลักแล้ว จำเป็นต้องมีวิธีการเสริมโดยไม่มีอาร์กิวเมนต์ ซึ่งส่งคืนตัวแปรสตริงที่มีข้อมูลทั้งหมดเกี่ยวกับวิธีการหลักที่รับประกันการทำงานของบริการเว็บและคำอธิบายรูปแบบของ พารามิเตอร์ที่ส่งผ่าน เช่นเดียวกับข้อมูลที่ส่งคืน ซึ่งรับประกันการจัดทำเอกสารด้วยตนเองของบริการเว็บ และความสามารถในการสร้างและปรับปรุงแอปพลิเคชันไคลเอนต์อย่างต่อเนื่องโดยไม่คำนึงถึงผู้พัฒนาบริการเว็บ

วิทยานิพนธ์จัดเตรียมเทคนิคในการจัดการการโทรไปยังวิธีการข้อมูลบริการเว็บโดยตรงจากสภาพแวดล้อมการพัฒนาแอปพลิเคชัน Java แบบรวม ซึ่งโดยใช้ URL ของบริการเว็บ คุณสามารถเข้าถึงการตอบสนอง Soap ของวิธีการข้อมูลและเนื้อหาของการส่งคืน ค่า.

ในบทที่สองมีการพิจารณาวิธีในการสร้างบริการเว็บ CAD แบบกระจาย ด้วยความช่วยเหลือในการคำนวณวงจรไม่เชิงเส้นในโหมดคงที่ ฟังก์ชันวงจรของวงจรเชิงเส้นและเชิงเส้นจะถูกคำนวณสำหรับโดเมนความถี่ และวงจรไม่เชิงเส้นจะถูกคำนวณในโหมดไดนามิก นอกจากนี้ ระบบย่อยที่รวมอยู่ในระบบแบบกระจายยังรวมถึงบริการบนเว็บสำหรับการคำนวณความไวของฟังก์ชันวงจรในโดเมนความถี่ และบริการบนเว็บสำหรับการคำนวณความไวของตัวแปรสถานะคงตัวของวงจรไม่เชิงเส้นต่อการแปรผันของพารามิเตอร์ ในฐานะที่เป็นส่วนประกอบของวงจรที่ออกแบบบนพื้นฐานของบริการบนเว็บที่พัฒนาขึ้น คุณสามารถใช้อุปกรณ์สองเทอร์มินัลประเภท R, C, L, แหล่งกำเนิดที่ควบคุมตามความถี่เชิงเส้น, แหล่งกำเนิดที่ควบคุมแบบไม่เชิงเส้น, หม้อแปลง, ทรานซิสเตอร์สองขั้วและขั้วเดียว เครื่องขยายเสียงในการดำเนินงานรวมถึงแหล่งจ่ายกระแสและแรงดันหลัก

พื้นฐานของวิธีการดังกล่าวคือโครงสร้างทั่วไปของคำอธิบายทางคณิตศาสตร์ของระบบการออกแบบวงจร วิทยานิพนธ์นี้เป็นการประเมินเปรียบเทียบวิธีการที่เป็นไปได้ในการเลือกพื้นฐานพิกัดเพื่อสร้างคำอธิบายของวงจรเชิงเส้นตรง โดยให้ความสำคัญกับพื้นฐานขยายของศักย์ไฟฟ้าปม มีข้อสังเกตว่านอกเหนือจากข้อดีที่ไม่ต้องสงสัยแล้ว ข้อจำกัดที่สำคัญของพื้นฐานนี้คือความเป็นไปไม่ได้ในการอธิบายส่วนประกอบของวงจรทางคณิตศาสตร์ด้วยสมการในรูปแบบโดยนัย ซึ่งมักจะซับซ้อนและบางครั้งก็ทำให้เป็นไปไม่ได้ในการประยุกต์ใช้ในทางปฏิบัติ เพื่อให้ทราบถึงความเป็นไปได้ในการอธิบายส่วนประกอบของวงจรด้วยสมการในรูปแบบโดยนัย งานนี้จึงได้จัดทำเวอร์ชันแก้ไขของแรงดันไฟฟ้าหลักแบบขยาย ซึ่งใช้เป็นพื้นฐานสำหรับการสร้างซอฟต์แวร์บริการเว็บ

เมื่อพิจารณาประเด็นที่เกี่ยวข้องกับการสร้างบริการเว็บสำหรับปัญหาในการคำนวณคุณสมบัติความถี่ของวงจรอิเล็กทรอนิกส์พบว่าปัญหาประเภทนี้สามารถแบ่งออกเป็นสองกลุ่ม กลุ่มแรกรวมถึงปัญหาในการคำนวณวงจรเชิงเส้นพารามิเตอร์ของส่วนประกอบที่มีค่าคงที่ซึ่งไม่ได้ขึ้นอยู่กับกระบวนการแก้ไขปัญหาเกี่ยวกับค่าพิกัดของจุดปฏิบัติการของส่วนประกอบ กลุ่มที่สองเกี่ยวข้องกับการคำนวณลักษณะความถี่ของวงจรเชิงเส้นซึ่งพารามิเตอร์นั้นขึ้นอยู่กับพิกัดของจุดปฏิบัติการของส่วนประกอบและพิกัดเหล่านี้ตลอดจนค่าของพารามิเตอร์เชิงเส้นตรงที่สอดคล้องกันจะต้องเป็น คำนวณไว้ล่วงหน้า

เพื่อแก้ปัญหากลุ่มแรกของการคำนวณคุณสมบัติความถี่ของวงจรอิเล็กทรอนิกส์เมื่อทำงานวิทยานิพนธ์จึงมีการสร้างบริการเว็บ ModService_Java เพื่อให้สามารถทำงานกับจำนวนเชิงซ้อนได้ในระหว่างการก่อสร้าง จึงได้สร้างคลาส Complex แบบกำหนดเองขึ้นมา เนื่องจากในขณะที่ทำงานนี้ คลาสดังกล่าวไม่ได้เป็นส่วนหนึ่งของเครื่องมือ Java API มาตรฐาน คลาส Complex ประกอบด้วยตัวสร้างและฟังก์ชันตัวช่วยสำหรับการประมวลผลข้อมูลที่ซับซ้อนและทุกสิ่ง ฟังก์ชั่นที่จำเป็นเพื่อดำเนินการเลขคณิตและ การดำเนินการเชิงตรรกะด้วยจำนวนเชิงซ้อน เนื่องจากภาษา Java ไม่มีตัวดำเนินการแทนที่สำหรับการดำเนินการเหล่านี้ บริการเว็บได้รับคำอธิบายของส่วนประกอบวงจรและคำสั่งการคำนวณเป็นอาร์กิวเมนต์ และส่งกลับอาร์เรย์ที่อธิบายผลลัพธ์ของการคำนวณลักษณะความถี่

หากต้องการคำนวณโหมดนิ่งอย่าทำ ระบบเชิงเส้นวิทยานิพนธ์เสนอวิธีการทั่วไปสำหรับการสร้างซอฟต์แวร์สำหรับบริการเว็บที่เกี่ยวข้อง ซึ่งนำไปใช้เมื่อสร้างบริการเว็บ StaticService_Java บริการบนเว็บยังได้รับคำอธิบายของส่วนประกอบวงจรและคำสั่งการคำนวณเป็นอาร์กิวเมนต์ และส่งกลับอาร์เรย์ที่อธิบายผลลัพธ์ของการคำนวณตัวแปรพื้นฐานและพิกัดสถานะคงที่สำหรับส่วนประกอบที่ไม่เชิงเส้นทั้งหมด (ไดโอด ทรานซิสเตอร์สองขั้ว, ทรานซิสเตอร์แบบยูนิโพลาร์, เครื่องขยายสัญญาณปฏิบัติการ, แหล่งควบคุมแบบไม่เชิงเส้น) องค์ประกอบที่ศูนย์ของอาร์เรย์ที่ส่งคืนถูกสงวนไว้สำหรับการส่งข้อมูลไปยังฝั่งไคลเอ็นต์ในกรณีที่ขาดการบรรจบกัน กระบวนการคำนวณซึ่งต้องเปลี่ยนคำสั่งการคำนวณและเรียกวิธีบริการเว็บอีกครั้ง

วิทยานิพนธ์จะตรวจสอบแนวทางที่เป็นไปได้ในการพัฒนาวิธีการสร้างบริการเว็บสำหรับการคำนวณลักษณะความถี่ของวงจรเชิงเส้นตรง ซึ่งพารามิเตอร์ขึ้นอยู่กับพิกัดของจุดปฏิบัติการของส่วนประกอบ จากผลการประเมินเปรียบเทียบ เส้นทางถูกเลือกเพื่อสร้างบริการเว็บโดยใช้ระบบรวม ซึ่งรวมถึงซอฟต์แวร์สำหรับการสร้างเชิงเส้นของส่วนประกอบที่ไม่เชิงเส้นที่จุดปฏิบัติการที่คำนวณ และสำหรับการคำนวณคุณสมบัติความถี่ของวงจรเชิงเส้นตรงในภายหลัง . งานนี้มีวิธีการทั่วไปในการแก้ปัญหาดังกล่าวซึ่งมีการดำเนินการในบริการเว็บ StFrqService_Java บริการเว็บได้รับคำอธิบายของส่วนประกอบที่ขึ้นกับความถี่และไม่เชิงเส้นของวงจรเป็นอาร์กิวเมนต์ตลอดจนคำสั่งการคำนวณและจากผลของการทำงานอาร์เรย์จะถูกส่งกลับเพื่ออธิบายผลลัพธ์ของการคำนวณลักษณะความถี่ เช่นเดียวกับการคำนวณสถานะคงตัว องค์ประกอบศูนย์ของอาร์เรย์ที่ส่งคืนจะถูกใช้เพื่อถ่ายโอนข้อมูลไปยังฝั่งไคลเอ็นต์ในกรณีที่กระบวนการไม่มาบรรจบกัน

เมื่อพัฒนาวิธีการสำหรับการสร้างบริการเว็บสำหรับการคำนวณโหมดไดนามิกของระบบไม่เชิงเส้นจะใช้คำอธิบายทางคณิตศาสตร์ของวงจรในรูปแบบขยายของศักยภาพที่สำคัญซึ่งทำให้สามารถรับระบบสมการประเภทพีชคณิต - ดิฟเฟอเรนเชียล ในรูปแบบทั่วไปที่สุด การกำจัดอนุพันธ์จากสมการองค์ประกอบจะดำเนินการบนพื้นฐานของสูตรการแก้ไขที่ตามมาจากวิธีการโดยนัยหลายขั้นตอนของลำดับที่สูงกว่า ในขณะที่วิธีเกียร์ลำดับที่สองถูกนำมาใช้เป็นวิธีหลักที่มีความเป็นไปได้ที่จะเพิ่มลำดับ ส่วนประกอบจากสมการที่ไม่รวมอนุพันธ์ ได้แก่ เครือข่ายสองขั้วประเภท C และ L, ไดโอด, หม้อแปลง, ทรานซิสเตอร์แบบไบโพลาร์และยูนิโพลาร์, เครื่องขยายสัญญาณปฏิบัติการ รวมถึงแหล่งกำเนิดที่ควบคุมตามความถี่ ในการคำนวณค่าของแหล่งอัตโนมัติที่รักษาค่าของตัวแปรที่เกี่ยวข้องในขั้นตอนก่อนหน้า ฟังก์ชันการสุ่มตัวอย่างเสริม dis_cmp จะถูกสร้างขึ้นสำหรับส่วนประกอบ cmp ที่ระบุไว้ทั้งหมดพร้อมคุณสมบัติที่ขึ้นกับความถี่

วิธีการที่พัฒนาขึ้นนั้นถูกนำไปใช้ในการสร้างบริการเว็บ Dyn2Service_Java ซึ่งส่งคืนอาร์เรย์ฝั่งไคลเอ็นต์ที่อธิบายผลลัพธ์ของการคำนวณลักษณะไดนามิก

ในบทที่สามพิจารณาถึงปัญหาของการสร้างบริการเว็บโดยใช้วิธีการบีบอัดข้อมูล ความเกี่ยวข้องของปัญหาเหล่านี้ถูกกำหนดโดยข้อเท็จจริงที่ว่าโครงสร้างของระบบจริงนั้นมีลักษณะเฉพาะด้วยการเชื่อมต่อที่อ่อนแอระหว่างส่วนประกอบต่างๆ ซึ่งส่งผลให้เกิดคำอธิบายทางคณิตศาสตร์ในรูปแบบของเมทริกซ์แบบกระจัดกระจาย ซึ่งมีเพียงส่วนเล็ก ๆ ขององค์ประกอบเท่านั้นที่มี ข้อมูลที่มีความหมาย

สถานการณ์นี้ทำให้เกิดการเปลี่ยนแปลงแนวทางที่เป็นที่ยอมรับโดยทั่วไปในการสร้างและการแก้สมการเพื่อประหยัดหน่วยความจำและเพิ่มประสิทธิภาพ ซึ่งเป็นสิ่งสำคัญสำหรับการทำงานของระบบบนเว็บ

งานวิทยานิพนธ์ได้วิเคราะห์ประสิทธิผลของวิธีการที่เป็นไปได้ในการแปลงข้อมูลเป็นอาร์เรย์ขนาดกะทัดรัดโดยได้ข้อสรุปเกี่ยวกับความเหมาะสมในการเลือกวิธีการตามการใช้การบีบอัดของ Sherman และต้องใช้ขั้นตอนสองขั้นตอนในการดำเนินการเชิงสัญลักษณ์และ การประมวลผลข้อมูลเชิงตัวเลข ข้อได้เปรียบที่สำคัญของขั้นตอนสองขั้นตอนที่นำมาใช้คือการแบ่งออกเป็นสองส่วนอิสระของขั้นตอนสัญลักษณ์และตัวเลข เนื่องจากปัญหาการออกแบบวงจรจริงเกือบทั้งหมดเกี่ยวข้องกับการคำนวณหลายตัวแปรของวงจรที่มีโครงสร้างไม่เปลี่ยนแปลง เวทีสัญลักษณ์จะดำเนินการสำหรับแต่ละโครงสร้างเพียงครั้งเดียว ในขณะที่ขั้นตอนตัวเลขถูกนำมาใช้เป็นสิบ ร้อย และบางครั้งหลายพันครั้ง

อย่างไรก็ตาม กระบวนการสองขั้นตอนนั้นมีลักษณะเฉพาะด้วยตรรกะที่ค่อนข้างซับซ้อนสำหรับการสร้างโค้ดโปรแกรม และเมื่อย้ายไปยังคำอธิบายตามการบีบอัดข้อมูล จำเป็นต้องมีการเปลี่ยนแปลงที่สำคัญในคำอธิบายที่สมบูรณ์ของปัญหาที่สร้างไว้ก่อนหน้านี้

วิทยานิพนธ์ตรวจสอบบล็อกไดอะแกรมของการดำเนินการประมวลผลข้อมูลสองขั้นตอนเมื่อสร้างแอปพลิเคชัน Java ซึ่งในขั้นตอนของการวิเคราะห์เชิงสัญลักษณ์เมทริกซ์ดัชนีของประเภทจำนวนเต็มจะเกิดขึ้นซึ่งขั้นตอนสัญลักษณ์ของการแยกตัวประกอบ LU คือ ดำเนินการโดยเรียงลำดับแถว (คอลัมน์) เพื่อลดจำนวนให้เหลือองค์ประกอบที่ปรากฏอีกครั้งด้วยค่าที่ไม่ใช่ศูนย์ ในขั้นตอนสุดท้ายของขั้นตอนสัญลักษณ์ เมทริกซ์พิกัดจะถูกสร้างขึ้นซึ่งมีข้อมูลเกี่ยวกับโครงสร้างของเมทริกซ์ดัชนี ซึ่งทำให้เมทริกซ์นี้สามารถลบออกได้

ในขั้นตัวเลข ตามรูปแบบคำอธิบายที่ทราบ จะมีการสร้างเมทริกซ์ขนาดกะทัดรัดขึ้น และการแยกตัวประกอบ LU เชิงตัวเลขเสมือนจะดำเนินการตามอัลกอริทึมที่สร้างขึ้นในงาน หลังจากเสร็จสิ้นขั้นตอนตัวเลขของการแยกตัวประกอบ LU แล้ว ตัวแปรระบบทั้งหมดจะถูกคำนวณและเข้ารหัสใหม่ตามการเรียงสับเปลี่ยนของแถว (คอลัมน์) ที่ดำเนินการในขั้นตอนการประมวลผลสัญลักษณ์ ตามเทคนิคการแยกตัวประกอบ LU ทั่วไป ปัญหานี้มักจะแก้ไขได้โดยใช้การเลื่อนไปข้างหน้าและข้างหน้าผ่านแถวของเมทริกซ์ดั้งเดิม แต่เนื่องจากไม่มีเมทริกซ์ที่สมบูรณ์เมื่อใช้การบีบอัดข้อมูล การเคลื่อนที่ไปข้างหน้าและข้างหลังจึงดำเนินการโดยใช้อัลกอริธึมพิเศษ ที่ดำเนินงานเหล่านี้โดยใช้การบีบอัดข้อมูล

วิทยานิพนธ์แสดงให้เห็นว่ามีแนวทางที่แตกต่างกันสองวิธีในการพัฒนาซอฟต์แวร์บริการเว็บโดยอิงจากการบีบอัดข้อมูล วิธีแรกเกี่ยวข้องกับการประมวลผลซอฟต์แวร์ที่มีอยู่ โดยอิงตามคำอธิบายทางคณิตศาสตร์ที่สมบูรณ์ในรูปแบบของเมทริกซ์ดั้งเดิมที่มีโครงสร้างแบบกระจัดกระจาย เพื่อสร้างวิธีการแก้ไขโดยใช้อาร์เรย์ขนาดกะทัดรัด การมีต้นแบบช่วยลดความยุ่งยากในการสร้างวิธีการตามการบีบอัดข้อมูลได้อย่างมาก แต่เพื่อให้การใช้วัสดุที่มีอยู่มีประสิทธิภาพสูงสุด จำเป็นต้องมีวิธีในการพัฒนาบริการเว็บเวอร์ชันดัดแปลง เทคนิคนี้สร้างขึ้นในวิทยานิพนธ์และบนพื้นฐานของบริการเว็บทั้งหมดที่กล่าวถึงข้างต้นได้รับการแก้ไข ผลลัพธ์ที่ได้คือเฟรมเวิร์กบริการเว็บที่มีวิธีการทำงานหลักสองวิธี วิธีหนึ่งอิงตามคำอธิบายแบบเต็มของวงจรแบบจำลอง และวิธีที่สองใช้เทคโนโลยีการประมวลผลข้อมูลขนาดกะทัดรัด

แนวทางที่สองใช้ในกรณีที่ไม่มีต้นแบบในการพัฒนาวิธีการตามการบีบอัดข้อมูล ในกรณีนี้ทั้งขั้นตอนสัญลักษณ์และตัวเลขจะถูกนำมาใช้ในกรณีที่ไม่มีคำอธิบายที่สมบูรณ์ของวงจรจำลองในรูปแบบของเมทริกซ์กระจัดกระจายซึ่งทำให้กระบวนการการเขียนโปรแกรมซับซ้อนมากขึ้น ในวิทยานิพนธ์ แนวทางที่สองใช้ในการสร้างบริการบนเว็บที่คำนวณความไวของการส่งสัญญาณของวงจรและตัวแปรโหมดคงที่ของวงจรต่อความแปรผันของพารามิเตอร์ของส่วนประกอบต่างๆ

ในการคำนวณความไวของลักษณะความถี่ของฟังก์ชันวงจร บริการเว็บ VaryService ถูกสร้างขึ้นซึ่งประกอบด้วยวิธีการที่ใช้การแยกความแตกต่างของสมการและวิธีการตามวงจรที่เชื่อมต่อ

ขึ้นอยู่กับความแตกต่างของสมการ วิธีการบริการเว็บ VaryService ช่วยให้คุณสามารถคำนวณค่าของความไวเวกเตอร์สัมบูรณ์และสัมพัทธ์ของฟังก์ชันวงจรสำหรับโดเมนความถี่ไปยังพารามิเตอร์ตัวแปรที่เลือกสำหรับตัวแปรพื้นฐานทั้งชุด พารามิเตอร์ตัวแปรอาจเป็นค่าความต้านทาน ความจุ หรือการเหนี่ยวนำของวงจรสองขั้วตามอำเภอใจประเภท R, C หรือ L และพารามิเตอร์การส่งผ่านของแหล่งที่ขึ้นกับความถี่ที่ควบคุม เช่น ITUN, INUN, ITUT หรือ INUT

วิธีการบริการเว็บ VaryService โดยใช้วงจรที่แนบมาช่วยให้คุณสามารถคำนวณค่าของความไวสเกลาร์ทั้งสัมบูรณ์และสัมพัทธ์ของฟังก์ชันวงจรสำหรับโดเมนความถี่โดยคำนึงถึงพารามิเตอร์ตัวแปรที่เป็นไปได้ทั้งหมดสำหรับค่าที่เลือกของตัวแปรที่วิเคราะห์ แผนภาพบล็อกซอฟต์แวร์ที่เสนอในงานนี้ช่วยให้คุณใช้ผลลัพธ์ของการก่อตัวของอาร์เรย์ขนาดกะทัดรัดของวงจรหลักเพื่อคำนวณวงจรที่ต่ออยู่ พารามิเตอร์ตัวแปรในวิธีการที่ใช้วงจรที่อยู่ติดกันสามารถเป็นพารามิเตอร์เดียวกันกับวิธีการที่ใช้ความแตกต่างของสมการได้

ในการคำนวณความไวของตัวแปรที่กำหนดโหมดคงที่ของวงจรไม่เชิงเส้นต่อการแปรผันของพารามิเตอร์ บริการเว็บ StVaryService ได้รับการพัฒนาขึ้น ซึ่งมีสองวิธีเช่นกัน วิธีหนึ่งขึ้นอยู่กับความแตกต่างของสมการ และวิธีที่สองในวิธีที่แนบมาด้วย วงจร พารามิเตอร์ตัวแปรในทั้งสองวิธีสามารถเป็นค่าความต้านทานของตัวต้านทานและพารามิเตอร์การส่งผ่านของแหล่งควบคุมเช่น ITUN, INUN, ITUT หรือ INUT

อัลกอริธึมสำหรับการคำนวณความไวสัมบูรณ์ของตัวแปรพื้นฐานของโหมดนิ่งโดยวิธีการหาความแตกต่างของสมการนั้นจัดให้มีการสร้างความแตกต่างของสมการไม่เชิงเส้นของวงจรด้วยตัวแปรพื้นฐานและพารามิเตอร์ตัวแปรซึ่งทำให้สามารถรับสมการความไวได้ วิธีแก้ปัญหาที่กำหนดความไวของเวกเตอร์ที่ต้องการของตัวแปรของโหมดคงที่

การนำวิธีนี้ไปปฏิบัติจริงนั้นขึ้นอยู่กับการสร้างความแตกต่างสมการของส่วนประกอบต่าง ๆ โดยใช้ผลลัพธ์ของการคำนวณตัวแปรพื้นฐานของโหมดคงที่ของวงจรไม่เชิงเส้น

อัลกอริธึมของวิธีการคำนวณความไวสเกลาร์ของตัวแปรโหมดคงที่โดยใช้วงจรที่อยู่ติดกันจัดให้มีการคำนวณตัวแปรพื้นฐานของโหมดนิ่งของวงจรหลักและการคำนวณตัวแปรพื้นฐานของวงจรเชื่อมต่อเชิงเส้นตรงซึ่งดำเนินการ บนพื้นฐานของอาร์เรย์ขนาดกะทัดรัดที่สร้างขึ้นก่อนหน้านี้สำหรับวงจรหลัก ผลลัพธ์ของวิธีที่สองคืออาร์เรย์ของค่าความไวสัมบูรณ์และสัมพัทธ์ของตัวแปรวงจรที่เลือกสำหรับพารามิเตอร์ส่วนประกอบตัวแปรทั้งหมด

บทที่สี่กล่าวถึงวิธีการสร้างแอปพลิเคชันไคลเอนต์แบบกำหนดเองที่ให้การโต้ตอบกับบริการเว็บ ซึ่งหลังจากสร้างด้วยเครื่องมือพัฒนาแอปพลิเคชัน Java แล้ว จะต้องปรับใช้บนเซิร์ฟเวอร์ CAD แบบกระจาย ในการปรับใช้บริการเว็บ คุณจำเป็นต้องทราบคุณสมบัติหลัก รวมถึงชื่อบริการ ชื่อคลาส ชื่อเมธอด และประเภทเอกสาร WSDL

ข้อมูลที่เกี่ยวข้องเกี่ยวกับบริการเว็บที่พัฒนาและอธิบายไว้ข้างต้นสำหรับระบบการออกแบบวงจรแบบกระจายมีให้ในวิทยานิพนธ์ และในวิธีการข้อมูลที่ชื่อว่า getInf ซึ่งรวมอยู่ในบริการเว็บที่พัฒนาแล้วทั้งหมด บทความนี้เสนอเทคนิคง่ายๆ สำหรับการปรับใช้บริการเว็บโดยตรงบนเซิร์ฟเวอร์ และอภิปราย วิธีที่เป็นไปได้การนำเข้าไฟล์ WSDL ไปยังฝั่งไคลเอ็นต์ จากการวิเคราะห์เปรียบเทียบ งานแสดงให้เห็นว่าการดำเนินการส่งไฟล์ WSDL จากบริการเว็บระยะไกลไปยังแอปพลิเคชันไคลเอนต์สามารถรับประกันความถูกต้องได้อย่างมีประสิทธิภาพสูงสุดโดยใช้เครื่องมือ Web Services Explorer และลำดับที่เหมาะสมที่สุดสำหรับการนำเข้า สร้างไฟล์ WSDL ลงในเฟรมเวิร์กเริ่มต้นของแอปพลิเคชันไคลเอนต์แล้ว

เมื่อไฟล์ WSDL ถูกส่งไปยังโปรเจ็กต์แอปพลิเคชันไคลเอ็นต์แล้ว จะมีการเสนอให้ดำเนินการแปลงโครงกระดูกโปรเจ็กต์เริ่มต้นเพิ่มเติมเป็นแอปพลิเคชันไคลเอนต์ที่สมบูรณ์ในสองขั้นตอน ขั้นตอนแรกของการเปลี่ยนแปลงคือการสร้างวัตถุพร็อกซีในกรอบงานโครงการเริ่มต้น และขั้นตอนที่สองคือการก่อตัวของคลาสที่มีวิธีการที่สนับสนุนการทำงานของวัตถุพร็อกซีและการโต้ตอบ บริการระยะไกลด้วยแอปพลิเคชันไคลเอนต์ การดำเนินการในระยะแรกนั้นคือการเสริมโครงการด้วยตัวดำเนินการที่สร้างวัตถุพร็อกซี ขั้นตอนที่สองดำเนินการโดยใช้เครื่องมือบริการเว็บของแพลตฟอร์ม WTP ซึ่งเป็นวิธีการใช้งานที่มีประสิทธิภาพสูงสุดซึ่งระบุไว้ในวิทยานิพนธ์

การสรุปโครงร่างการออกแบบเริ่มต้นให้เป็นแอปพลิเคชันไคลเอนต์ที่สมบูรณ์สามารถทำได้หลายวิธีสำหรับแอปพลิเคชันประเภทต่างๆ วิธีที่ง่ายที่สุดในการรันแอปพลิเคชันไคลเอนต์คือการออกแบบตามแอปพลิเคชันคอนโซลที่ไม่มีอินเทอร์เฟซแบบกราฟิก เสนอผลงานแบบทั่วไป โครงการโครงสร้างการใช้แอปพลิเคชันคอนโซล CAD แบบกระจายสำหรับการคำนวณวงจรอิเล็กทรอนิกส์ ซึ่งสามารถใช้สำหรับบริการเว็บใดๆ แม้จะมีโซลูชันเฉพาะที่เป็นไปได้ที่หลากหลายก็ตาม

ในระหว่างวิทยานิพนธ์ แอปพลิเคชันคอนโซลไคลเอนต์ได้ถูกนำไปใช้สำหรับบริการเว็บ CAD แบบกระจายข้างต้นทั้งหมด สามารถส่งไฟล์ต้นฉบับได้ วิธีการมาตรฐานผ่านอินเทอร์เน็ตไปยังไคลเอนต์และใช้ทั้งเพื่อสร้างแอปพลิเคชันคอนโซลเวอร์ชันที่ง่ายที่สุดสำหรับการโต้ตอบกับบริการ CAD แบบกระจายและเป็นสื่อการสอนสำหรับการพัฒนาแอปพลิเคชันหน้าต่างขั้นสูงเพิ่มเติม

แอปพลิเคชันไคลเอนต์แบบมีหน้าต่างให้ โอกาสที่ยิ่งใหญ่ที่สุดสำหรับการทำงานในรูปแบบ CAD แบบกระจาย เนื่องจากทำให้สามารถใช้องค์ประกอบกราฟิกได้ในระดับสูงสุด สำหรับบริการบนเว็บนี้ คุณสามารถสร้างแอปพลิเคชันไคลเอ็นต์เวอร์ชันต่างๆ ได้ด้วยวิธีต่างๆ ในการจัดการสนทนากับผู้ใช้และแสดงผลการคำนวณ งานนี้ได้สร้างชุดเครื่องมือโต้ตอบขั้นต่ำเพื่อให้แน่ใจว่ามีการโต้ตอบกับบริการอย่างสมบูรณ์ ชุดดังกล่าวประกอบด้วยเมนูหน้าต่างและชุดกล่องโต้ตอบสำหรับการป้อนข้อมูลและแสดงผลการคำนวณตลอดจนการจัดการคำสั่งการคำนวณ

วิทยานิพนธ์เสนอวิธีการสำหรับการสร้างแอปพลิเคชันเว็บไคลเอนต์บนพื้นฐานของเทมเพลตหน้า JSP ได้รับการพัฒนาซึ่งทำหน้าที่ในการเลือกและย้ายไปยังหน้าอื่น ๆ ป้อนชุดตัวแปรบางชุดพร้อมการเปลี่ยนไปยังหน้าแรกโดยเข้าสู่แบบวนรอบ ชุดตัวแปรบางชุดพร้อมการเปลี่ยนไปยังหน้าถัดไปตามค่าของตัวแปรเหล่านี้ เรียกบริการเว็บที่ต้องการและแสดงผลลัพธ์ของการดำเนินการ การใช้แอปพลิเคชันเว็บไคลเอ็นต์ช่วยให้คุณสามารถวางรหัสโปรแกรมทั้งหมดของระบบแบบกระจายบนเครือข่ายและขึ้นอยู่กับวิธีการที่นำมาใช้ในการวางแอปพลิเคชันไคลเอนต์และเซิร์ฟเวอร์บนเครือข่าย การเรียกใช้บริการสามารถทำได้จากที่ใดที่หนึ่งหรือจาก หลายหน้าเว็บ

คุณลักษณะเชิงบวกของสถาปัตยกรรมนี้คือความสามารถในการจัดระเบียบการเข้าถึง CAD แบบกระจายผ่านเว็บเบราว์เซอร์ที่กำหนดเองโดยไม่จำเป็นต้องสร้างแอปพลิเคชันไคลเอนต์ของคุณเอง ข้อเสียของแนวทางในการจัดการ CAD แบบกระจายนี้คือการเพิ่มขึ้นอย่างหลีกเลี่ยงไม่ได้ในช่วงเวลาที่ต้องอธิบาย ส่วนประกอบของระบบในกระบวนการโต้ตอบแบบโต้ตอบ

วิทยานิพนธ์สร้างระเบียบวิธีในการจัดการกระบวนการปรับใช้แอปพลิเคชันไคลเอนต์ โดยมีวัตถุประสงค์เพื่อให้แน่ใจว่าสามารถเปิดแอปพลิเคชันไคลเอนต์โดยใช้เครื่องมือทั้งระบบโดยไม่ต้องใช้เครื่องมือพัฒนาแอปพลิเคชัน ในขณะที่ทั้งสำหรับแอปพลิเคชันไคลเอนต์ประเภทคอนโซลและสำหรับ แอปพลิเคชันไคลเอ็นต์ประเภทหน้าต่าง การเปิดตัวควรดำเนินการผ่าน บรรทัดคำสั่งและสำหรับเว็บแอปพลิเคชัน - จากเบราว์เซอร์ ข้อมูลเกี่ยวกับตำแหน่งของบริการเว็บจะถูกส่งผ่านวัตถุคลาสพร็อกซีซึ่งจะต้องกำหนดค่าเป็น URL ที่เหมาะสมก่อน

งานตั้งข้อสังเกตว่าเมื่อปรับใช้แอปพลิเคชันคอนโซล ต้องเปลี่ยนโค้ดเพจโครงการก่อน ซึ่งจำเป็นต้องย้ายจากโค้ดเพจที่มีข้อความซีริลลิกแสดงอยู่ในระบบเครื่องมือรวมทั้งหมดที่ทำงานกับโค้ด Java ไปยังโค้ดเพจ ซึ่งข้อความซีริลลิกจะแสดงตามปกติในหน้าต่างบรรทัดคำสั่ง

วิทยานิพนธ์แสดงให้เห็นว่าเมื่อใช้เว็บแอปพลิเคชันไคลเอนต์ ขึ้นอยู่กับโครงสร้างการสื่อสารที่เลือกระหว่างคอมพิวเตอร์ไคลเอนต์และเซิร์ฟเวอร์ ข้อมูลเกี่ยวกับตำแหน่งของบริการเว็บสามารถส่งผ่านทั้งวัตถุคลาสพร็อกซีและผ่าน URL ที่ป้อนจากเบราว์เซอร์ วิธีการโต้ตอบของลูกค้ากับบริการที่เกี่ยวข้องเมื่อใช้งานการทำงานสำหรับโครงสร้างการสื่อสารที่เลือกจะถูกกล่าวถึงในงานด้วย

การกำหนดมาตรฐาน SOAP ให้ความสามารถในการเชื่อมต่อระหว่างแอปพลิเคชันที่เชื่อมต่อแบบหลวมๆ โดยไม่คำนึงถึงแพลตฟอร์มการใช้งาน ซึ่งช่วยให้ใช้บริการเว็บเพื่อให้แน่ใจว่าการใช้งานทรัพยากรที่เชื่อมต่อแบบหลวมๆ ที่ต่างกันหลากหลายในแอปพลิเคชันแบบกระจายนั้นมีประสิทธิภาพและเหมาะสมที่สุด วิทยานิพนธ์นี้ให้วิธีการทั่วไปสำหรับการสร้างซอฟต์แวร์สำหรับการโต้ตอบอ็อบเจ็กต์ของคลาสพร็อกซีของแอปพลิเคชัน .NET ด้วยบริการของสภาพแวดล้อม Java/J2EE ตามวิธีการนี้ องค์กรของการโต้ตอบระหว่างบริการเว็บ Java ที่พัฒนาแล้วและแอปพลิเคชันไคลเอนต์ Windows ที่สร้างขึ้นในสภาพแวดล้อม .NET ที่ใช้ภาษา C# ได้ถูกนำมาใช้

ความสามารถในการใช้งาน CAD แบบกระจายในสภาพแวดล้อมที่แตกต่างกันช่วยขยายขอบเขตการใช้งานได้อย่างมาก

อยู่ในความควบคุมตัวมีการกำหนดผลลัพธ์ทางวิทยาศาสตร์และการปฏิบัติหลักที่ได้รับจากการวิจัยที่ดำเนินการในวิทยานิพนธ์

ผลลัพธ์หลักการทำงาน 1. สถาปัตยกรรมสำหรับ CAD ที่มุ่งเน้นบริการแบบกระจายโดยอิงจากบริการบนเว็บได้รับการพัฒนา โดยมีจุดเด่นคือโครงสร้างแบบกระจายอำนาจ ความเป็นอิสระของแพลตฟอร์ม และความสามารถในการดำเนินการปรับปรุงระบบย่อยแต่ละระบบให้ทันสมัยอย่างต่อเนื่อง เพื่อปรับคุณสมบัติให้เข้ากับเงื่อนไขการออกแบบที่เปลี่ยนแปลง

2. มีการนำวิธีการทั่วไปมาใช้ในการสร้างบริการเว็บ Java และเอกสาร WSDL ที่เกี่ยวข้องโดยใช้วิธีการจากล่างขึ้นบน รวมถึงการส่งมอบไปยังเซิร์ฟเวอร์ CAD แบบกระจายหลังจากการทดสอบออฟไลน์ในสภาพแวดล้อมการพัฒนา

3. วิธีการได้รับการพัฒนาสำหรับการสร้างซอฟต์แวร์สำหรับบริการเว็บ Java เพื่อแก้ไขปัญหาทั่วไปของการสร้างแบบจำลองระบบต่อเนื่องในการออกแบบวงจรอิเล็กทรอนิกส์อัตโนมัติ

4. ไลบรารีของฟังก์ชันเสริมถูกสร้างขึ้นเพื่อใช้ซอฟต์แวร์บริการเว็บ Java โดยอาศัยการบีบอัดข้อมูล

5. วิธีการทั่วไปสำหรับการสร้างเทมเพลตสำหรับแอปพลิเคชันไคลเอ็นต์คอนโซลและหน้าต่างสำหรับระบบอัตโนมัติของการออกแบบวงจรแบบกระจายได้รับการพัฒนา และมีการใช้การจัดระบบการทำงานของระบบ CAD แบบกระจายกับแอปพลิเคชันเว็บไคลเอนต์

6. วิธีการได้รับการพัฒนาสำหรับการสร้างระบบ CAD แบบกระจายที่รับรองการโต้ตอบของบริการเว็บ Java และแอปพลิเคชันไคลเอนต์ ประเภทใดก็ได้ในสภาพแวดล้อมที่แตกต่างกัน

1. อานิซิมอฟ ดี.เอ. การสร้างระบบการออกแบบโดยใช้คอมพิวเตอร์ช่วยโดยอิงจากบริการบนเว็บ [ข้อความ] / Anisimov D.A. Gridin V.N., Dmitrevich G.D. // ระบบอัตโนมัติในอุตสาหกรรม – 2011 – ฉบับที่ 1 – หน้า 9-12

2. อนิซิมอฟ ดี.เอ. การสร้างระบบการออกแบบโดยใช้คอมพิวเตอร์ช่วยโดยใช้เทคโนโลยีเว็บ [ข้อความ] / Gridin V.N., Dmitrevich G.D., Anisimov D.A. // เทคโนโลยีสารสนเทศ - 2554 - ลำดับที่ 5 – หน้า 23-27.

3. อนิซิมอฟ ดี.เอ. การสร้างบริการเว็บสำหรับระบบอัตโนมัติในการออกแบบวงจร [ข้อความ] / Gridin V.N., Dmitrevich G.D., Anisimov D.A // เทคโนโลยีสารสนเทศและระบบคอมพิวเตอร์ - 2555 - ลำดับที่ 4 – หน้า 79-84.

4. อนิซิมอฟ ดี.เอ. วิธีสร้างระบบอัตโนมัติสำหรับการออกแบบวงจรตามบริการบนเว็บ [ข้อความ] / Anisimov D.A. // ข่าวของ St. Petersburg Electrotechnical University "LETI" - 2012. - ลำดับที่ 10 – เซนต์ปีเตอร์สเบิร์ก: สำนักพิมพ์ของมหาวิทยาลัยเทคนิคไฟฟ้าเซนต์ปีเตอร์สเบิร์ก “LETI”, – หน้า 56-61

5. อนิซิมอฟ ดี.เอ. การเข้าถึงทรัพยากรบนเว็บในระบบนำทางและควบคุม CAD [ข้อความ] / Laristov D.A., Anisimov D.A. // ไจโรสโคปและการนำทาง พ.ศ. 2550 ลำดับที่ 2 –ส. 106.

บริการเว็บ- คำใหม่ในเทคโนโลยีระบบแบบกระจาย ข้อมูลจำเพาะ สภาพแวดล้อมเน็ตแบบเปิด (ONE)ซัน ไมโครซิสเต็มส์ คอร์ปอเรชั่น และโครงการริเริ่ม Net ของ Microsoft จัดเตรียมโครงสร้างพื้นฐานสำหรับการเขียนและการปรับใช้บริการเว็บ ใน ตอนนี้มีคำจำกัดความหลายประการของบริการบนเว็บ บริการเว็บอาจเป็นแอปพลิเคชันใดๆ ที่สามารถเข้าถึงเว็บได้ เช่น เว็บเพจที่มีเนื้อหาแบบไดนามิก ในแง่ที่แคบกว่า บริการเว็บคือแอปพลิเคชันที่ให้อินเทอร์เฟซแบบเปิดที่แอปพลิเคชันอื่นบนเว็บใช้งานได้ ข้อกำหนด ONE Sun กำหนดให้บริการเว็บสามารถเข้าถึงได้ผ่าน HTTP และเว็บโปรโตคอลอื่นๆ เพื่อให้มีการแลกเปลี่ยนข้อมูลผ่านข้อความ XML และสามารถค้นหาได้ผ่าน บริการพิเศษ- บริการค้นหา มีการพัฒนาโปรโตคอลพิเศษสำหรับการเข้าถึงบริการบนเว็บ - เรียบง่าย การเข้าถึงวัตถุโปรโตคอล (SOAP)ซึ่งแนะนำการทำงานร่วมกันแบบ XML สำหรับบริการเว็บจำนวนมาก บริการบนเว็บมีความน่าสนใจเป็นพิเศษเนื่องจากสามารถให้ความเข้ากันได้ในระดับสูงระหว่างระบบต่างๆ

บริการเว็บสมมุติที่พัฒนาขึ้นตามสถาปัตยกรรม ONE ของ Sun อาจอยู่ในรูปแบบของการลงทะเบียนบริการที่เผยแพร่คำอธิบายของบริการเว็บเป็นเอกสาร .

ศักยภาพมหาศาลของบริการบนเว็บไม่ได้ถูกกำหนดโดยเทคโนโลยีที่ใช้ในการสร้างบริการเหล่านั้น HTTP, XML และโปรโตคอลอื่นๆ ที่ใช้โดยบริการบนเว็บไม่ใช่เรื่องใหม่ การทำงานร่วมกันและความสามารถในการปรับขนาดของบริการบนเว็บหมายความว่านักพัฒนาสามารถสร้างแอปพลิเคชันขนาดใหญ่ขึ้นและบริการบนเว็บที่ใหญ่ขึ้นจากบริการบนเว็บขนาดเล็กได้อย่างรวดเร็ว ข้อกำหนดของ Sun Open Net Environment อธิบายสถาปัตยกรรมสำหรับการสร้าง บริการเว็บอัจฉริยะ.บริการเว็บอัจฉริยะใช้ประโยชน์จากสภาพแวดล้อมการทำงานทั่วไป ด้วยการแบ่งปันบริบท บริการเว็บอัจฉริยะสามารถตรวจสอบความถูกต้องมาตรฐานสำหรับธุรกรรมทางการเงิน ให้คำแนะนำและคำแนะนำตามที่ตั้งทางภูมิศาสตร์ของบริษัทที่เกี่ยวข้องกับการทำธุรกรรม ธุรกิจอิเล็กทรอนิกส์.

ในการสร้างแอปพลิเคชันที่เป็นบริการบนเว็บ จำเป็นต้องใช้เทคโนโลยีหลายอย่าง

ความสัมพันธ์ระหว่างเทคโนโลยีเหล่านี้แสดงตามอัตภาพในรูป 10.1.

ข้าว. 10.1.

ในความเป็นจริง บริการเว็บเป็นหนึ่งในตัวเลือกการใช้งาน สถาปัตยกรรมส่วนประกอบซึ่งแอปพลิเคชันถือเป็นชุดของส่วนประกอบที่มีการโต้ตอบกัน ดังที่ได้กล่าวไปแล้วหลายครั้งว่าปฏิสัมพันธ์ของส่วนประกอบต่างๆดำเนินไป แพลตฟอร์มที่แตกต่างกันถือเป็นงานที่ค่อนข้างซับซ้อนโดยเฉพาะต้องมีการพัฒนา โปรโตคอลการสื่อสาร โดยคำนึงถึงคุณสมบัติการถ่ายโอนข้อมูลระหว่างแพลตฟอร์มต่างๆ หนึ่งในแนวคิดหลักที่เป็นรากฐานของเทคโนโลยีบริการเว็บที่กำลังพิจารณาคือการปฏิเสธไบนารี่ โปรโตคอลการสื่อสาร. ข้อความมีการแลกเปลี่ยนระหว่างส่วนประกอบของระบบโดยการส่งข้อความ XML เนื่องจากข้อความ XML เป็นไฟล์ข้อความ โปรโตคอลการส่งผ่านข้อมูลอาจแตกต่างกันมาก - ข้อความ XML สามารถส่งผ่านโปรโตคอล HTTP, SMTP, FTP และการใช้โปรโตคอลการขนส่งที่แตกต่างกันจึงโปร่งใสสำหรับแอปพลิเคชัน ดังที่ได้กล่าวไปแล้ว เรียกว่าโปรโตคอลที่อนุญาตให้บริการบนเว็บโต้ตอบได้ สบู่ (โปรโตคอลการเข้าถึงวัตถุอย่างง่าย). มันถูกกำหนดตาม XML สบู่ช่วยให้มั่นใจถึงปฏิสัมพันธ์ของระบบแบบกระจาย โดยไม่คำนึงถึงโมเดลออบเจ็กต์หรือแพลตฟอร์มที่ใช้ ข้อมูลภายใน สบู่ส่งในรูปแบบของเอกสาร XML ในรูปแบบพิเศษ สบู่ไม่ได้กำหนดระเบียบวิธีการขนส่งเฉพาะใดๆ อย่างไรก็ตามใน การใช้งานจริงการถ่ายโอนมักใช้บ่อยที่สุด สบู่-ข้อความผ่านโปรโตคอล HTTP ยังใช้กันอย่างแพร่หลายในการขนส่ง โปรโตคอล SMTP, FTP และแม้แต่ TCP "บริสุทธิ์" ดังนั้น, สบู่กำหนดกลไกที่บริการเว็บสามารถเรียกใช้ฟังก์ชันของกันและกันได้ ในแง่หนึ่ง การทำงานของโปรโตคอลนี้ชวนให้นึกถึงการเรียกขั้นตอนระยะไกล - ผู้เรียกรู้ชื่อของบริการบนเว็บ ชื่อของวิธีการ พารามิเตอร์ที่วิธีการยอมรับ และทำการโทรไปยังวิธีนี้อย่างเป็นทางการในรูปแบบ สบู่-ข้อความและส่งไปยังบริการบนเว็บ

อย่างไรก็ตาม วิธีการที่อธิบายไว้จะเหมาะสมก็ต่อเมื่อทราบ "ลายเซ็น" ของวิธีการที่บริการเว็บนำไปใช้ล่วงหน้าเท่านั้น แต่ถ้าไม่เป็นเช่นนั้นล่ะ? เพื่อแก้ไขปัญหานี้ได้มีการนำเลเยอร์เพิ่มเติมมาสู่โมเดลบริการเว็บ - เลเยอร์สำหรับอธิบายอินเทอร์เฟซบริการ เลเยอร์นี้แสดงเป็นคำอธิบาย WSDL.

ตามที่กำหนดโดย W3C " WSDL - รูปแบบ XMLสำหรับคำอธิบาย บริการเครือข่ายเป็นชุดของการดำเนินการที่มีขอบเขตจำกัดซึ่งดำเนินการโดยใช้ข้อความที่มีข้อมูลเชิงเอกสารหรือเชิงขั้นตอน" เอกสาร WSDLอธิบายอินเทอร์เฟซของบริการเว็บกับโลกภายนอกอย่างสมบูรณ์ โดยให้ข้อมูลเกี่ยวกับบริการที่สามารถรับได้โดยใช้วิธีการบริการและวิธีการเข้าถึงวิธีการเหล่านี้ ดังนั้น หากไม่ทราบลายเซ็นวิธีการของบริการบนเว็บอย่างชัดเจน (เช่น มีการเปลี่ยนแปลงเมื่อเวลาผ่านไป) ก็สามารถสอบถามบริการเว็บเป้าหมายได้ WSDL-description - ไฟล์ที่จะมีข้อมูลนี้

เทคโนโลยีอีกชั้นหนึ่งคือการบริการ คำอธิบายสากล การค้นพบและการบูรณาการ (UDDI)เทคโนโลยีนี้เกี่ยวข้องกับการบำรุงรักษารีจิสทรีของบริการบนเว็บ ด้วยการเชื่อมต่อกับรีจิสทรีนี้ ผู้บริโภคสามารถค้นหาบริการทางเว็บที่ตรงกับความต้องการของเขามากที่สุด เทคโนโลยี อุดดีทำให้สามารถค้นหาและเผยแพร่บริการที่ต้องการได้ และการดำเนินการเหล่านี้สามารถทำได้โดยบุคคลหรือโดยบริการเว็บอื่นหรือโปรแกรมไคลเอนต์พิเศษ อุดดีในทางกลับกัน ยังเป็นบริการบนเว็บอีกด้วย

ดังนั้นบริการเว็บจึงเป็นการนำระบบไปใช้อีกอย่างหนึ่ง มิดเดิลแวร์. คุณสมบัติที่โดดเด่นของเทคโนโลยีนี้คือความเป็นอิสระจากซอฟต์แวร์ที่ใช้และ ฮาร์ดแวร์รวมไปถึงการใช้กันอย่างแพร่หลาย มาตรฐานแบบเปิด(เช่น XML) และโปรโตคอลการสื่อสารมาตรฐาน

ปัจจุบันบริการบนเว็บเป็นเทคโนโลยีที่ได้รับการส่งเสริมอย่างมากและอยู่ในตำแหน่งที่เป็นวิธีการแก้ปัญหาหลายประการ

ควรสังเกตว่าการใช้งานที่เรียกว่าแอปพลิเคชัน "มาตรฐาน" ก็สามารถสร้างได้เช่นกัน โดยที่ส่วนของเซิร์ฟเวอร์ได้รับการออกแบบเป็นบริการบนเว็บ

โปรโตคอลการเข้าถึงวัตถุอย่างง่าย (SOAP)

โปรโตคอลพื้นฐานที่รับประกันการโต้ตอบในสภาพแวดล้อมบริการเว็บคือ

บทที่ 1 วิธีการทั่วไปสำหรับการสร้างระบบแบบกระจายตามบริการเว็บ

1.1. สถาปัตยกรรมเชิงบริการ

1-2. ระเบียบวิธีสำหรับการสร้างบริการเว็บ Java

1-3. การทดสอบบริการเว็บเบื้องต้น

บทที่ 2 วิธีการสร้างซอฟต์แวร์สำหรับบริการเว็บของระบบอัตโนมัติการออกแบบวงจรแบบกระจาย

2-1. การสนับสนุนทางคณิตศาสตร์สำหรับระบบอัตโนมัติในการออกแบบวงจร

2-2. บริการเว็บสำหรับการออกแบบระบบเชิงเส้นในโดเมนความถี่

2-3. บริการเว็บสำหรับคำนวณสถานะคงที่ของระบบไม่เชิงเส้น

2-4. ระบบบูรณาการที่เน้นการบริการสำหรับการวิเคราะห์ความถี่ของวงจรเชิงเส้นตรง

2-5. บริการเว็บสำหรับการคำนวณระบบไม่เชิงเส้นในโหมดไดนามิก

บทที่ 3 การสร้างบริการเว็บโดยใช้วิธีการบีบอัดข้อมูล

3-1. วิธีการกำจัด องค์ประกอบเป็นศูนย์ระหว่างการจัดเก็บและประมวลผลเมทริกซ์

3-2. ระเบียบวิธีในการพัฒนาบริการเว็บเวอร์ชันดัดแปลง

3-2-1. การปรับเปลี่ยนในขั้นตอนเชิงสัญลักษณ์

3-2-2. การปรับเปลี่ยนในระยะตัวเลข

3-3. บริการเว็บสำหรับคำนวณความไวของฟังก์ชันวงจรต่อการแปรผันของพารามิเตอร์

3-3-1. การสร้างวิธีการบริการเว็บโดยอาศัยการหาอนุพันธ์ของสมการ

3-3-2. วิธีการบริการเว็บตามสคีมาที่แนบมา

3-4. บริการเว็บสำหรับการคำนวณความไวของตัวแปรสถานะคงตัว

3-4-1. การสร้างวิธีการบริการเว็บสำหรับการคำนวณความไวของเวกเตอร์ของตัวแปร

3-4-2. วิธีการบริการเว็บสำหรับการคำนวณความไวสเกลาร์ของตัวแปร

บทที่ 4 วิธีการสร้างแอปพลิเคชันไคลเอ็นต์ของระบบ CAD แบบกระจาย

4-1. เทคนิคสำหรับการสร้างแอปพลิเคชันไคลเอนต์ตามเอกสาร WSDL

4-1-1. การปรับใช้บริการเว็บบน เซิร์ฟเวอร์อาปาเช่แมวตัวผู้

4-1-2. เทคนิคในการนำเข้าไฟล์ WSDL และสร้างแอปพลิเคชันไคลเอ็นต์โครงกระดูก

4-2. การใช้งานไคลเอ็นต์ของระบบการออกแบบวงจรแบบกระจาย

4-2-1. วิธีการสร้างไคลเอ็นต์คอนโซล

4-2-2. ระเบียบวิธีสำหรับการสร้างแอปพลิเคชันไคลเอนต์แบบหน้าต่าง

4-2-3. ระเบียบวิธีสำหรับการสร้างเว็บแอปพลิเคชันไคลเอนต์

4-3. การปรับใช้แอปพลิเคชัน Java ไคลเอนต์

4-3-1. การปรับใช้แอปพลิเคชันไคลเอ็นต์ Java ที่เรียกใช้จากบรรทัดคำสั่ง

4-3-2. การปรับใช้แอปพลิเคชันไคลเอนต์ Java ที่เปิดตัวจากเว็บเบราว์เซอร์

4-4. การจัดระเบียบปฏิสัมพันธ์ของแอปพลิเคชันไคลเอนต์กับบริการเว็บในสภาพแวดล้อมที่ต่างกัน

การแนะนำวิทยานิพนธ์ (ส่วนหนึ่งของบทคัดย่อ) ในหัวข้อ "การวิจัยและพัฒนาวิธีสร้างระบบการออกแบบโดยใช้คอมพิวเตอร์ช่วยแบบกระจายโดยใช้เทคโนโลยีบริการเว็บ"

การนำระบบการออกแบบโดยใช้คอมพิวเตอร์ช่วยมาใช้อย่างกว้างขวางในการแก้ปัญหาทางวิศวกรรมนั้นมีข้อจำกัดอย่างมากด้วยต้นทุนซอฟต์แวร์ CAD ที่มีลิขสิทธิ์สูง ในขณะเดียวกัน การสร้างระบบการออกแบบโดยใช้คอมพิวเตอร์ช่วยของคุณเองนั้นเกี่ยวข้องกับต้นทุนทรัพยากรมหาศาล และไม่สามารถทำได้ในระยะเวลาอันสั้น เนื่องจากการพัฒนาระบบ CAD สมัยใหม่ต้องใช้แรงงานหลายร้อยปี ปัญหายังซับซ้อนด้วยความจริงที่ว่าในสถานการณ์การทำงานจริงนั้นระบบ CAD ในตัวแบบมัลติฟังก์ชั่น (เช่น Micro-Cap 7, PSPICE, DISPC) ถูกใช้ตามกฎแล้วไม่มีประสิทธิภาพอย่างมากเนื่องจากในกระบวนการแก้ไขปัญหาเฉพาะจาก ซอฟต์แวร์พื้นฐานของระบบเหล่านี้ ไม่เกิน 10-20% ของซอฟต์แวร์ที่เฉพาะเจาะจงมากที่สุดสำหรับแต่ละแผนก

วิธีแก้ปัญหาเร่งด่วนนี้อาจเป็นการกระจายอำนาจของสถาปัตยกรรม CAD โดยการย้ายไปยังระบบการออกแบบแบบกระจายที่สร้างขึ้นบนพื้นฐานของเทคโนโลยีอินเทอร์เน็ตที่ดำเนินงานการสื่อสารและการแลกเปลี่ยนข้อมูลระหว่างแอปพลิเคชัน แอปพลิเคชันที่ได้รับการจัดการอย่างอิสระเหล่านี้ทำงานอัตโนมัติและสามารถสื่อสารระหว่างกันเพื่อทำงานทั่วไปให้สำเร็จได้ โปรโตคอลเทคโนโลยีอินเทอร์เน็ตให้พื้นฐานที่เชื่อถือได้สำหรับการเชื่อมโยงระบบย่อย และไม่เหมือนกับเทคโนโลยีกริดตรงที่ไม่จำเป็นต้องใช้ทรัพยากรร่วมกันซึ่งอยู่ในโหนดเครือข่ายที่แตกต่างกัน ซึ่งทำให้กระบวนการสร้างและใช้งานระบบ CAD แบบกระจายง่ายขึ้นอย่างมาก ข้อกำหนดหลักสำหรับความเป็นไปได้ในการใช้งานระบบแบบกระจายคือความสอดคล้องของอินเทอร์เฟซที่ระบบย่อยแต่ละระบบสามารถโต้ตอบซึ่งกันและกันได้ หากเป็นไปตามข้อกำหนดนี้ นักพัฒนาหลายๆ คนสามารถสร้างส่วนประกอบแต่ละส่วนของระบบ CAD แบบกระจายได้ และดูแลรักษาไว้ในไซต์ต่างๆ จากที่ที่จะส่งมอบ ซึ่งอาจเป็นแบบเชิงพาณิชย์ไปยังผู้บริโภค

วิธีที่มีประสิทธิภาพมากที่สุดสำหรับการรวมระบบย่อยแต่ละระบบเข้ากับแอปพลิเคชันแบบกระจายคือการเรียกขั้นตอนระยะไกลตามสถาปัตยกรรมเชิงบริการโดยใช้เทคโนโลยีบริการเว็บ บูรณาการตามบริการเว็บในการพัฒนาระบบ CAD แบบกระจายอำนาจช่วยให้คุณสามารถไปยังคำอธิบายของอินเทอร์เฟซและการโต้ตอบตาม XML โดยให้ความสามารถในการแก้ไขและพัฒนาซอฟต์แวร์โดยมีเงื่อนไขว่าอินเทอร์เฟซที่เลือกจะยังคงอยู่ เนื่องจากการมีเพศสัมพันธ์ที่หลวมของระบบย่อยแต่ละระบบ ช่วยให้มั่นใจได้ถึงการโต้ตอบระหว่างบริการต่างๆ บนแพลตฟอร์มใดๆ และเพื่อปรับแอปพลิเคชันที่มีอยู่ให้เข้ากับเงื่อนไขการออกแบบที่เปลี่ยนแปลงไป

ภาระหลักของการดำเนินการคำนวณด้วยสถาปัตยกรรมดังกล่าวตกอยู่ที่บริการบนเว็บซึ่งช่วยแก้ปัญหาทั้งหมดของการสร้างแบบจำลองระบบที่ได้รับการออกแบบ แอปพลิเคชันไคลเอนต์จะได้รับมอบหมายเฉพาะฟังก์ชันที่ง่ายที่สุดในการเตรียมข้อมูลเริ่มต้นและแสดงผลการสร้างแบบจำลอง เมื่อสร้างระบบ CAD โดยใช้เทคโนโลยีบริการเว็บ แอปพลิเคชันไคลเอนต์ประเภทต่อไปนี้สามารถนำไปใช้ได้: แอปพลิเคชันประเภทคอนโซล แอปพลิเคชันประเภทหน้าต่าง และแอปพลิเคชันเว็บ

คุณลักษณะของแอปพลิเคชันคอนโซลคือการไม่มีอินเทอร์เฟซแบบกราฟิก อย่างไรก็ตาม การใช้งานจะมีประโยชน์เมื่อใช้ระบบ CAD แบบง่ายสำหรับพ็อกเก็ตคอมพิวเตอร์ที่มีพื้นที่หน้าจอขนาดเล็ก

แอปพลิเคชั่นหน้าต่างทำให้สามารถใช้อินเทอร์เฟซแบบกราฟิกได้ดีที่สุดและเหมาะสมที่สุดสำหรับการพัฒนาระบบ CAD ที่ใช้เทคโนโลยีบริการเว็บ ในเวลาเดียวกัน สำหรับบริการเว็บใดๆ คุณสามารถสร้างแอปพลิเคชันประเภทเดียวกันได้หลายแอปพลิเคชันพร้อมวิธีโต้ตอบโต้ตอบแบบต่างๆ

เว็บแอปพลิเคชันช่วยให้สามารถวางซอฟต์แวร์ระบบการออกแบบแบบกระจายทั้งหมดบนอินเทอร์เน็ตได้อย่างสมบูรณ์ ข้อดีของแอปพลิเคชันโครงสร้างดังกล่าวคือการเข้าถึงแบบเปิดสำหรับการใช้ CAD แบบกระจายผ่านเบราว์เซอร์ประเภทใดก็ได้ ข้อเสียของแอปพลิเคชันประเภทนี้คือการเพิ่มเวลาที่ต้องใช้ในการป้อนคำอธิบายของส่วนประกอบของแบบจำลอง ระบบที่เกิดจากการคาดหวังปฏิกิริยาในแต่ละขั้นตอนของการป้อนข้อมูลเริ่มต้น

สำหรับแอปพลิเคชันไคลเอนต์ทุกประเภท บริการทางเว็บจะถูกเรียกใช้ในลักษณะเดียวกัน และสำหรับแต่ละบริการบนเว็บ คุณสามารถใช้วิธีใดก็ได้เพื่อสร้างแอปพลิเคชันไคลเอนต์ที่เขียนด้วยภาษาโปรแกรมที่แตกต่างกัน หากจำเป็น แอปพลิเคชันไคลเอนต์ดังกล่าวสามารถแก้ไขได้อย่างง่ายดายตามเงื่อนไขการออกแบบที่เปลี่ยนแปลง นอกจากนี้ยังสามารถขยายบริการเว็บโดยรวมวิธีการเพิ่มเติมได้อีกด้วย

วิทยานิพนธ์นี้มีวัตถุประสงค์เพื่อวิจัยและพัฒนาวิธีการสร้างระบบการออกแบบโดยใช้คอมพิวเตอร์ช่วยแบบกระจายโดยไม่ขึ้นกับแพลตฟอร์ม บนสถาปัตยกรรมเชิงบริการโดยใช้เทคโนโลยีบริการเว็บ สำหรับการใช้งานเฉพาะ งานที่เลือกคือการสร้างระบบอัตโนมัติแบบกระจายสำหรับการออกแบบวงจร ซึ่งควรทำการสร้างแบบจำลองหลายตัวแปรของวงจรอิเล็กทรอนิกส์เชิงเส้นและไม่เชิงเส้นในโหมดคงที่ ในโดเมนความถี่ ในโดเมนเวลา และยังคำนวณความไวด้วย ของฟังก์ชันวงจร (ถ่ายโอน) และความไวของตัวแปรโหมดคงที่ต่อการแปรผันของพารามิเตอร์

เพื่อให้บรรลุภารกิจนี้ จำเป็น:

พัฒนาวิธีการทั่วไปสำหรับการสร้าง การทดสอบออฟไลน์ และการปรับใช้บริการเว็บ Java บนเซิร์ฟเวอร์

ดำเนินการวิจัยและพัฒนาซอฟต์แวร์บริการเว็บ Java สำหรับระบบอัตโนมัติในการออกแบบวงจรแบบกระจาย

วิจัยและพัฒนาระเบียบวิธีสำหรับการสร้างบริการเว็บ Java โดยใช้เทคโนโลยีการบีบอัดข้อมูล

ดำเนินการวิจัยและพัฒนาวิธีการทั่วไปสำหรับการสร้างเทมเพลตสำหรับแอปพลิเคชันไคลเอนต์ประเภทคอนโซลและหน้าต่าง รวมถึงเว็บแอปพลิเคชันไคลเอนต์

พัฒนาวิธีการสำหรับการนำการทำงานของบริการเว็บไปใช้ในสภาพแวดล้อมที่ต่างกัน

วิทยานิพนธ์ประกอบด้วยคำนำ เนื้อหาหลัก 4 บท บทสรุป และบรรณานุกรม 69 ชื่อเรื่อง งานนี้นำเสนอด้วยข้อความ 154 หน้า ประกอบด้วยตัวเลข 21 ตัว และตาราง 1 ตาราง

บทสรุปของวิทยานิพนธ์ ในหัวข้อ "การออกแบบระบบอัตโนมัติ (ตามอุตสาหกรรม)", Anisimov, Denis Andreevich

ผลลัพธ์หลักของงานวิทยานิพนธ์มีดังนี้:

1. สถาปัตยกรรมสำหรับ CAD ที่มุ่งเน้นบริการแบบกระจายโดยอิงจากบริการบนเว็บได้รับการพัฒนา โดยมีจุดเด่นคือโครงสร้างแบบกระจายอำนาจ ความเป็นอิสระของแพลตฟอร์ม และความสามารถในการดำเนินการปรับปรุงระบบย่อยแต่ละระบบให้ทันสมัยอย่างต่อเนื่อง เพื่อปรับคุณสมบัติให้เข้ากับเงื่อนไขการออกแบบที่เปลี่ยนแปลงไป

2. มีการนำวิธีการทั่วไปมาใช้ในการสร้างบริการเว็บ Java และเอกสาร WSDL ที่เกี่ยวข้องโดยใช้วิธีการจากล่างขึ้นบน รวมถึงการส่งมอบไปยังเซิร์ฟเวอร์ CAD แบบกระจายหลังจากการทดสอบออฟไลน์ในสภาพแวดล้อมการพัฒนา

3. วิธีการได้รับการพัฒนาสำหรับการสร้างซอฟต์แวร์บริการเว็บ Java เพื่อแก้ไขปัญหาการสร้างแบบจำลองทั่วไป ระบบต่อเนื่องในการออกแบบวงจรอิเล็กทรอนิกส์แบบอัตโนมัติ

4. ไลบรารีของฟังก์ชันเสริมถูกสร้างขึ้นเพื่อใช้ซอฟต์แวร์บริการเว็บ Java โดยอาศัยการบีบอัดข้อมูล

5. วิธีการทั่วไปสำหรับการสร้างเทมเพลตสำหรับคอนโซลและแอปพลิเคชันไคลเอ็นต์หน้าต่างของระบบอัตโนมัติการออกแบบวงจรแบบกระจายได้รับการพัฒนา และมีการใช้การจัดระบบการทำงานของระบบ CAD แบบกระจายพร้อมแอปพลิเคชันเว็บไคลเอนต์

6. วิธีการได้รับการพัฒนาสำหรับการสร้างระบบ CAD แบบกระจายที่รับรองการโต้ตอบของบริการเว็บ Java และแอปพลิเคชันไคลเอนต์ทุกประเภทในสภาพแวดล้อมที่ต่างกัน

บทสรุป

เมื่อปฏิบัติงานวิทยานิพนธ์ ได้มีการพิจารณาประเด็นการวิจัยและพัฒนาวิธีการสร้างระบบ CAD แบบกระจายที่ไม่ขึ้นกับแพลตฟอร์มด้วยสถาปัตยกรรมเชิงบริการและการใช้บริการเว็บ เพื่อระบุระบบ CAD ดังกล่าว จึงเลือกระบบแบบกระจายสำหรับแก้ไขปัญหาการออกแบบวงจร

งานแสดงให้เห็นว่าการใช้บริการเว็บเมื่อสร้างซอฟต์แวร์ CAD แบบกระจายอำนาจทำให้สามารถอธิบายอินเทอร์เฟซและการโต้ตอบตาม XML โดยให้โอกาสในการแก้ไขและพัฒนาระบบโดยมีเงื่อนไขว่า อินเทอร์เฟซที่จำเป็น. ซึ่งช่วยให้คุณสามารถจัดระเบียบการโต้ตอบระหว่างบริการบนแพลตฟอร์มใดๆ และปรับใช้แอปพลิเคชันที่ใช้ในการเปลี่ยนแปลงเงื่อนไขการออกแบบ

งานนี้ได้สร้างวิธีการทั่วไปสำหรับการสร้าง การทดสอบออฟไลน์ และการปรับใช้บริการเว็บ Java บนเซิร์ฟเวอร์ จากวิธีการนี้ การใช้งานซอฟต์แวร์ของบริการเว็บ Java ได้รับการพัฒนาขึ้นเพื่อแก้ปัญหาการคำนวณวงจรอิเล็กทรอนิกส์เชิงเส้นและไม่เชิงเส้นในโหมดสภาวะคงตัว ในโดเมนความถี่ ในโดเมนเวลา รวมถึงการคำนวณความไวของฟังก์ชันวงจรและความคงที่ -mode ตัวแปรไปสู่การเปลี่ยนแปลงพารามิเตอร์ โครงสร้างของซอฟต์แวร์นั้นขึ้นอยู่กับการใช้งานเทคโนโลยีการบีบอัดข้อมูลและฟังก์ชั่นเสริมอย่างกว้างขวางซึ่งเป็นไลบรารีที่ถูกสร้างขึ้นในกระบวนการทำงานวิทยานิพนธ์ให้เสร็จสิ้น

เพื่อจัดระเบียบการโต้ตอบของผู้ใช้กับบริการเว็บอย่างมีประสิทธิภาพ เราได้พัฒนาขึ้น วิธีการทั่วไปการสร้างเทมเพลตสำหรับแอปพลิเคชันไคลเอนต์ประเภทคอนโซลและหน้าต่าง รวมถึงเว็บแอปพลิเคชันไคลเอนต์และการนำการทำงานของบริการเว็บไปใช้ในสภาพแวดล้อมที่ต่างกัน

รายการอ้างอิงสำหรับการวิจัยวิทยานิพนธ์ ผู้สมัครวิทยาศาสตร์เทคนิค Anisimov, Denis Andreevich, 2013

1. ข้อความการออกแบบวงจรอัตโนมัติ: เอกสาร / V.N. Ilyin [et al.]; แก้ไขโดย วี.เอ็น. อิลิน่า อ.: วิทยุและการสื่อสาร 2530 - 368 หน้า

2. ระบบอัตโนมัติของการออกแบบวงจรบนมินิคอมพิวเตอร์ ข้อความ: หนังสือเรียน / V.I. Anisimov [ฯลฯ ] JL: สำนักพิมพ์ Leningr มหาวิทยาลัย พ.ศ. 2526 - 252 น.

3. อานิซิมอฟ, V.I. ชุดแพ็คเกจแบบโต้ตอบสำหรับการสร้างแบบจำลองวงจรอิเล็กทรอนิกส์แอนะล็อกและดิจิทัลบน IBM/PC Text / V.I.Anisimov, K.B.Skobeltsyn, A.V.Nikitin // การออกแบบอัตโนมัติในอุปกรณ์อิเล็กทรอนิกส์ทางวิทยุและการผลิตเครื่องดนตรี: 1991.-P.3-6

4. อานิซิมอฟ, V.I. ความไวของระบบไม่เชิงเส้นต่อการเปลี่ยนแปลงพารามิเตอร์ข้อความ / V.I.Anisimov, Yu.M.Amakhvr // การดำเนินการของมหาวิทยาลัยเทคนิคไฟฟ้าเซนต์ปีเตอร์สเบิร์ก "LETI" เซอร์ สารสนเทศ การจัดการ และเทคโนโลยีคอมพิวเตอร์ -2550 ประเด็นที่ 2. - หน้า 22-26.

5. อานิซิมอฟ, V.I. การสร้างแบบจำลองระบบต่อเนื่อง ข้อความ: หนังสือเรียน / V.I. Anisimov SPb.: LETI, 2006. - 172 น.

6. Bellignaso, M. การพัฒนาแอปพลิเคชันเว็บในสภาพแวดล้อม ASP.NET 2.0 ข้อความ: เอกสาร / M. Bellignaso.; เลน จากอังกฤษ แก้ไขโดย ยู.เอ็น. อาร์เตเมนโก. อ.: LLC "I.D. Williams", 2550 - 640 หน้า

7. Bellman, R. ทฤษฎีเมทริกซ์เบื้องต้น ข้อความ: เอกสาร / R. Bellman; เลน จากอังกฤษ แก้ไขโดย วี.บี. ลิดสกี้. อ.: Nauka, 2512. - 336 น.

8. บ็อกดานอฟ, A.B. สถาปัตยกรรมที่มุ่งเน้นการบริการ: โอกาสใหม่ในแง่ของการพัฒนาเทคโนโลยี GRID / A.V. Bogdanov, E.N. Stankova, V.V. Mareev (http//www.ict.edu.ru/lib/index.php?idres= 5639)

9. Vlah, I. วิธีการวิเคราะห์และออกแบบวงจรอิเล็กทรอนิกส์ของเครื่องจักร ข้อความ: เอกสาร / I. Vlah, K. Singhal.; เลน จากอังกฤษ อ.: วิทยุและการสื่อสาร, 2531. - 560 น.

10. Gamma, E. เทคนิคการออกแบบเชิงวัตถุ ข้อความ: เอกสาร / E. Gamma, R. Helm.; เลน จากอังกฤษ เซนต์ปีเตอร์สเบิร์ก: ปีเตอร์ 2544

11. I. Gerber, Sh. หนังสืออ้างอิงฉบับสมบูรณ์เกี่ยวกับข้อความ C#: monograph / Sh. Gerber.; เลน จากอังกฤษ เซนต์ปีเตอร์สเบิร์ก: ปีเตอร์ 2549 - 740 หน้า

12. กลอริโอซอฟ อี.แอล. ความรู้เบื้องต้นเกี่ยวกับระบบอัตโนมัติของการออกแบบวงจร ข้อความ: เอกสาร / E.L. Gloriozov, V.G. Sorin, P.P. Sypchuk อ.: วิทยุโซเวียต, 2519 - 232 น.

13. Daconta, M. XML และ Java 2. ข้อความไลบรารีของโปรแกรมเมอร์: เอกสาร / M. Daconta, A. Saganich; เลน จากอังกฤษ เซนต์ปีเตอร์สเบิร์ก: 2544 - 384 หน้า

14. Dey, N. Eclipse: ข้อความแพลตฟอร์มเครื่องมือเว็บ: เอกสาร / N. Dey, L. Mandel, A. Rayman; เลน จากอังกฤษ อ.:, 2551.- 688 หน้า

15. ไดเทล พระบาทสมเด็จพระเจ้าอยู่หัว เทคโนโลยีการเขียนโปรแกรมใน Java 2: เล่ม 1 กราฟิก, JavaBeans, ส่วนต่อประสานกับผู้ใช้ ข้อความ: เอกสาร / H.M.Deitel, P.D.Deitel, S.I.Santry.; อ.: Binom-Press LLC, 2003.-560 หน้า

16. ไดเทล พระบาทสมเด็จพระเจ้าอยู่หัว เทคโนโลยีการเขียนโปรแกรมใน Java 2: เล่ม 2 แอปพลิเคชันแบบกระจาย ข้อความ: เอกสาร / Kh.M. Deitel, P. D. Deitel, S. I. Santry.; อ.: Binom-Press LLC, 2003.-464 หน้า

17. ไดเทล พระบาทสมเด็จพระปรมินทรมหาภูมิพลอดุลยเดช เทคโนโลยีการเขียนโปรแกรมใน Java 2: เล่ม 3 ระบบองค์กร เซิร์ฟเล็ต JSP บริการเว็บ ข้อความ: เอกสาร / H.M.Deitel, P.D.Deitel, S.I.Santry; เลน จากอังกฤษ อ.: Binom-Press LLC, 2546. - 672 หน้า

18. เดมิโดวิช บี.พี. ข้อความพื้นฐานของคณิตศาสตร์เชิงคำนวณ: เอกสาร / B.P. Demidovich, I.A. Maron อ.: ฟิซแมทกิซ, 2506. - 658 น.

19. James, O. วิธีการวนซ้ำสำหรับการแก้ระบบสมการไม่เชิงเส้น ข้อความ: เอกสาร / O. James, R. Vener.; เลน จากอังกฤษ แก้ไขโดย อี.วี. Vershkova, N.P. Zhidkova, I.V. โคโนวัลต์เซวา. อ.: มีร์, 2518.- 551 หน้า

20. George, A. ผลเฉลยเชิงตัวเลขของระบบสมการกระจัดกระจายขนาดใหญ่ ข้อความ: เอกสาร / A. George, J. Liu.; เลน จากอังกฤษ เอช.ดี. Ikramova M.: มีร์, 1984. - 333 น.

21. ระบบกล่องโต้ตอบของการออกแบบวงจร ข้อความ: เอกสาร / V.I. Anisimov [ฯลฯ ] อ.: วิทยุและการสื่อสาร 2531 - 287 หน้า

22. ดูนาเยฟ เอส.บี. Java สำหรับอินเทอร์เน็ตบน Windows และ ข้อความลินุกซ์.: เอกสาร / S.B. Dunaev. อ.: DIALOG-MEPhI, 2547. - 496 หน้า

23. เซเลนูคิน่า วี.เอ. การพัฒนาห้องปฏิบัติการเสมือนที่ใช้อินเทอร์เน็ตสำหรับการสร้างแบบจำลองทางคณิตศาสตร์โดยแยกงานด้านการคำนวณและการแสดงภาพออกจากกัน / V.A.Zelenukhina, // เทคโนโลยีสารสนเทศ, 2553 หมายเลข 10 - กับ.

24. ซิคอฟ เอ.เอ. พื้นฐานของทฤษฎีกราฟ ข้อความ: เอกสาร / A.A. Zykov -ม.: Nauka, 1987.-256 น.

25. อิลยิน, V.N. พื้นฐานของการออกแบบวงจรอัตโนมัติ ข้อความ: เอกสาร / V.N. Ilyin อ.: พลังงาน, 2522. - 391 น.

26. การสร้างแบบจำลองการจำลองระบบการผลิต ข้อความ: เอกสาร / A.A. Vavilov [et al.] เคียฟ: Tekhnika, 1983. - 415 น.

27. วิธีเขียนโปรแกรมในรูปแบบ XML Text: monograph / H.M. Deitel, [etc.].; เลน จากอังกฤษ อ.: สำนักพิมพ์ ZAO BINOM, 2544. - 944 หน้า

28. กาลิตคิน, N.H. วิธีการเชิงตัวเลข ข้อความ: เอกสาร / N.N. Kalitkin -ม.: Nauka, 1978, - 519 น.

29. Knuth, D. ศิลปะแห่งการเขียนโปรแกรมคอมพิวเตอร์ ข้อความ: เอกสาร / D.Knut.; เลน จากอังกฤษ G.P.Bavenko, Yu.M.Vayakovsky; แก้ไขโดย เคไอ บาเบนโก้ ปะทะ ชตาร์กแมน อ.: มีร์ 2519 - 734 หน้า

30. คริสโทฟิเดส เอ็น. ทฤษฎีกราฟ. ข้อความแนวทางอัลกอริทึม: เอกสาร / N. Christofides; เลน จากอังกฤษ แก้ไขโดย จีพี กาฟริโลวา. อ.: มีร์, 2521.-432 หน้า

31. MacDonald, M. Microsoft ASP.NET 2.0 พร้อมตัวอย่างใน C# 2005 สำหรับมืออาชีพ ข้อความ: เอกสาร / M. MacDonald, M. Shpushta; เลน จากอังกฤษ แก้ไขโดย ยู.เอ็น. อาร์เตเมนโก. อ.: LLC "I.D. Williams", 2549 - 1408 น.

32. มิคาอิลอฟ, V.B. วิธีการวิเคราะห์เชิงตัวเลขสำหรับการแก้ระบบสมการเชิงอนุพันธ์ - พีชคณิตแบบ superrigid ข้อความ: monograph / V.B. Mikhailov เซนต์ปีเตอร์สเบิร์ก: Nauka, 2548 - 223 น.

33. Norenkov, I.P. ความรู้เบื้องต้นเกี่ยวกับการออกแบบอุปกรณ์และระบบทางเทคนิคโดยใช้คอมพิวเตอร์ช่วย ข้อความ: เอกสาร / I.P. Norenkov -ม.: มัธยมปลาย, 2529. 302 น.

34. Norenkov, I.P. พื้นฐานของทฤษฎี CAD และการออกแบบ ข้อความ: เอกสาร / I.P. Norenkov, V.B. Manichev อ.: 1990. -334 น.

35. Norenkov, I.P. ระบบการออกแบบโดยใช้คอมพิวเตอร์ช่วยสำหรับอุปกรณ์อิเล็กทรอนิกส์และคอมพิวเตอร์ ข้อความ: เอกสาร / I.P. Norenkov, V.B. Manichev -ม.: มัธยมศึกษาตอนปลาย, 2526. 272 ​​​​น.

36. Naughton, P. Java 2 ข้อความ: เอกสาร / P. Naughton, G. Schildt ; เลน จากอังกฤษ เซนต์ปีเตอร์สเบิร์ก: BHV-Petersburg, 2544 - 1,072 หน้า

37. Petrenko, A.I. พื้นฐานของการสร้างระบบการออกแบบโดยใช้คอมพิวเตอร์ช่วย ข้อความ: เอกสาร / A.I. Petrenko, O.I. Semenkov -เคียฟ: โรงเรียนมัธยมปลาย 2527 293 หน้า

38. Petrenko, A.I. วิธีการตารางการสร้างแบบจำลองวงจรอิเล็กทรอนิกส์บนคอมพิวเตอร์ดิจิทัล ข้อความ: เอกสาร / A.I. Petrenko, A.I.Vlasov, A.P.Timchenko -เคียฟ: โรงเรียนมัธยมปลาย 2520 186 หน้า

39. Pissanetski, S. เทคโนโลยีของเมทริกซ์แบบเบาบาง ข้อความ: เอกสาร / S. Pissanetski; เลน จากอังกฤษ แก้ไขโดย ค.ดี.อิกราโมวา อ.: มีร์ 2531 - 410 น.

40. Razevig, V. การสร้างแบบจำลองวงจรโดยใช้ Micro-Cap 7 ข้อความ: เอกสาร / V. Razevig อ.: โทรคมนาคม, 2546. - 368 น.

41. การพัฒนาแอปพลิเคชันแบบกระจายบนแพลตฟอร์ม Microsoft กรอบงานสุทธิข้อความ: เอกสาร / S. Morgan [et al.].; เลน จากอังกฤษ อ.: “ฉบับรัสเซีย”, 2551 - 608 หน้า

42. การพัฒนาแอปพลิเคชันเว็บไคลเอนต์บนแพลตฟอร์ม Microsoft .Net Framework ข้อความ: เอกสาร / Glenn D. [et al.].; เลน จากอังกฤษ อ.: “ฉบับรัสเซีย”, 2550 - 768 หน้า

43. ข้อความคู่มือนักพัฒนา Borland JBuilder: เอกสาร / M. Lendi [et al.].; เลน จากอังกฤษ อ.: สำนักพิมพ์ "วิลเลียม", 2547. -864 หน้า

44. Rice, J. Matrix การคำนวณและซอฟต์แวร์ทางคณิตศาสตร์ ข้อความ: เอกสาร / J. Rice.; เลน จากอังกฤษ อ.: มีร์ 2527 - 264 หน้า

45. C# สำหรับมืออาชีพ ข้อความ: เอกสาร / Simon Robinson [et al.].; เลน จากอังกฤษ S. Korotygin [และอื่น ๆ ]. อ.: ลอริ 2548 - 1,002 หน้า

46. ​​​​ไซมอน พี. Microsoft Windows 2000 API ข้อความสารานุกรมโปรแกรมเมอร์: เอกสาร / R. Simon; เซนต์ปีเตอร์สเบิร์ก: DiaSoft, 2002.-1088 หน้า

47. ความลับของการเขียนโปรแกรมสำหรับอินเทอร์เน็ตในข้อความ Java: เอกสาร / M. Thomas [et al.].; เลน จากอังกฤษ เซนต์ปีเตอร์สเบิร์ก: ปีเตอร์, 1997. - 640 น.

48. Seshu, S. กราฟเชิงเส้นและ วงจรไฟฟ้าข้อความ: เอกสาร / S.Seshu, M.B.Rid.; เลน จากอังกฤษ อ.: มัธยมปลาย, 2514. - 448 น.

49. Sigorsky รองประธาน อัลกอริทึมสำหรับการวิเคราะห์วงจรอิเล็กทรอนิกส์ ข้อความ: /

50. V.P.Sigorsky, A.I.Petrenko อ.: วิทยุโซเวียต 2519 - 606 หน้า

51. Sigorsky รองประธาน เครื่องมือทางคณิตศาสตร์ของวิศวกร ข้อความ: เอกสาร / V.P. Sigorsky เคียฟ: Tekhnika, 1975. - 765 น.

52. สลิปเชนโก้, วี.จี. อัลกอริธึมของเครื่องและโปรแกรมสำหรับการสร้างแบบจำลองวงจรอิเล็กทรอนิกส์ ข้อความ: เอกสาร / V.G. Slipchenko, V.G. Tabarny - เคียฟ: เทคโนโลยี, 1976. 157 น.

53. Sovetov, B.Ya. การสร้างแบบจำลองของระบบ ข้อความ: เอกสาร / B.Ya.Sovetov,

54. เอส.เอ. ยาโคฟเลฟ อ.: มัธยมปลาย, 2528. - 271 น.

55. โซลนิทเซฟ, อาร์. ไอ. การออกแบบระบบอัตโนมัติ ควบคุมอัตโนมัติข้อความ: เอกสาร / R.I. Solnitsev อ.: มัธยมปลาย, 2534. - 328 น.

56. โซลนิทเซฟ, อาร์. ไอ. พื้นฐานของระบบอัตโนมัติในการออกแบบระบบไจโรสโคปิก ข้อความ: เอกสาร / R.I. โซลนิทเซฟ. อ.: มัธยมปลาย, 2528. - 240 น.

57. สเตปาเนนโก, ไอ.พี. ความรู้พื้นฐานของไมโครอิเล็กทรอนิกส์: หนังสือเรียน คู่มือสำหรับมหาวิทยาลัย ข้อความ / I.P. Stepanenko อ.: วิทยุโซเวียต, 2523. -567 หน้า

58. วรสิก วี.พี. การสร้างแบบจำลองทางคณิตศาสตร์ของระบบเทคนิค ข้อความ: เอกสาร / V.P. ทาราสิค. มินสค์: ออกแบบ PRO, 2004. - 639 น.

59. Troelsen, E. ภาษาการเขียนโปรแกรม C# 2005 และแพลตฟอร์ม .NET 2.0 ข้อความ: เอกสาร / E. Troelsen; เลน จากอังกฤษ แก้ไขโดย เอ.จี. สปิวัค. อ.: LLC "I.D. Williams", 2550 - 1168 หน้า

60. เทวาร์สัน F.R. ข้อความเมทริกซ์กระจัดกระจาย: เอกสาร / F.R. Tewarson; เลน จากอังกฤษ อ.: มีร์ 2520 - 189 หน้า

61. ฟาดีฟ ดี.เค. วิธีการคำนวณพีชคณิตเชิงเส้น ข้อความ: เอกสาร / D.K. Fadeev, V.N. ฟาดีวา. อ.: สำนักพิมพ์ Fiz-mat Literature, 2506. - 734 น.

62. Ferrara, A. การเขียนโปรแกรมบริการเว็บสำหรับ .NET Text: เอกสาร / A. Ferrara, M. MacDonald เซนต์ปีเตอร์สเบิร์ก: ปีเตอร์ 2546 - 422 หน้า

63. Forsythe, J. วิธีการของเครื่องจักร การคำนวณทางคณิตศาสตร์ข้อความ: เอกสาร / J. Forsythe, M. Malcolm, K. Mowler.; เลน จากอังกฤษ แก้ไขโดย ค.ดี.อิกราโมวา อ.: มีร์ 2523 - 277 หน้า

64. ฉาบ เอ.เอ. เทคโนโลยีสำหรับการสร้างระบบแบบกระจาย ข้อความ: เอกสาร / A.A. Tsimbal, M.L. Anshina เซนต์ปีเตอร์สเบิร์ก: ปีเตอร์ 2546 - 576 หน้า

65. ชัว ล.โอ. การวิเคราะห์วงจรอิเล็กทรอนิกส์ด้วยเครื่องจักร ข้อความ: เอกสาร / L.O.Chua, Lin.Pen-Min.; เลน จากอังกฤษ -ม.: พลังงาน, 2523. 631 น.

66. Heineman, P. PSPICE การสร้างแบบจำลองการทำงานของวงจรอิเล็กทรอนิกส์ ข้อความ: เอกสาร / R. Heineman -ม.: สำนักพิมพ์ DMK, 2548. 327 น.

67. Khabibulin, I. การพัฒนาบริการเว็บโดยใช้ Java Text: monograph / I. Khabibulin เซนต์ปีเตอร์สเบิร์ก: BHV-Petersburg, 2546 - 400 น.

68. ข้อความหน้า Hall, M. Servlets และ JavaServer: เอกสาร / M. Hall; เลน จากอังกฤษ -SPb.: ปีเตอร์ 2544 496 หน้า

69. Esterby, O. วิธีการโดยตรงสำหรับเมทริกซ์แบบกระจาย ข้อความ: เอกสาร / O. Esterby, Z. Zlatev; เลน จากอังกฤษ อ.: มีร์ 2530 - 111 น.

70. นพ. ยัง ไมโครซอฟต์ XML ข้อความทีละขั้นตอน: เอกสาร / M.D. Young; เลน จากอังกฤษ -อ.: สำนักพิมพ์เอคอม, 2545. 384 หน้า 69. http://bigor.bmstu.ru/?doc=080IS/ai006.mod/?cou-140CADedu/CAD.cou

โปรดทราบข้างต้น ตำราทางวิทยาศาสตร์โพสต์เพื่อวัตถุประสงค์ในการให้ข้อมูลและได้รับผ่านการรู้จำข้อความวิทยานิพนธ์ต้นฉบับ (OCR) ดังนั้นอาจมีข้อผิดพลาดที่เกี่ยวข้องกับอัลกอริธึมการรู้จำที่ไม่สมบูรณ์ ไม่มีข้อผิดพลาดดังกล่าวในไฟล์ PDF ของวิทยานิพนธ์และบทคัดย่อที่เราจัดส่ง