เหตุใดจึงไม่มีภาษาที่มุ่งเน้นบริการ

แก้ไข:

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

เดิม:

ในฟิลด์การเขียนโปรแกรมที่จำเป็นเราเห็นกระบวนทัศน์สองรายการในช่วง 20 ปีที่ผ่านมา (หรือมากกว่า): object-oriented (OO) และ service-oriented (SO) ส่วนประกอบตาม (CB)

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

อย่างไรก็ตามมีเพียง OO เท่านั้นที่มีภาษาการเขียนโปรแกรมซึ่งสนับสนุนกระบวนทัศน์ของมัน: Smalltalk, C ++, Java และอื่น ๆ ทั้งหมดที่เข้ากันได้กับ JVM, C # และอื่น ๆ ที่รองรับ NET., Python ฯลฯ

ดังนั้นจึงไม่มีภาษาพื้นเมืองดังกล่าว มันมีอยู่ในการดำรงอยู่ด้านบนของภาษาขั้นตอนหรือภาษา OO: COM / DCOM (ไบนารี, C, C ++), CORBA, EJB, ฤดูใบไม้ผลิ, Guice (Java ทั้งหมด), ...

กรอบการทำงานของ SO เหล่านี้เห็นได้ชัดจากการสนับสนุนแนวคิดดั้งเดิมของภาษาที่หายไป

• พวกเขาเริ่มใช้คลาส OO เพื่อเป็นตัวแทนบริการและบันทึก สิ่งนี้นำไปสู่การออกแบบที่มีความแตกต่างที่ชัดเจนระหว่างคลาสที่มีวิธีการเท่านั้น (บริการ) และผู้ที่มีสาขาเท่านั้น (บันทึก) มรดกระหว่างบริการหรือบันทึกนั้นจะถูกจำลองโดยการสืบทอดของคลาส ในทางเทคนิคแล้วมันไม่ได้ถูกเก็บไว้อย่างเข้มงวด แต่โดยทั่วไปแล้วโปรแกรมเมอร์แนะนำให้ทำการเล่นเฉพาะหนึ่งในสองบทบาท
• พวกเขาใช้ภาษาภายนอกเพิ่มเติมเพื่อแสดงชิ้นส่วนที่ขาดหายไป: IDL's, การกำหนดค่า XML, คำอธิบายประกอบในรหัส Java หรือแม้แต่ DSL ที่ฝังอยู่เช่นใน Guice สิ่งนี้จำเป็นอย่างยิ่ง แต่ไม่ จำกัด เฉพาะเนื่องจากองค์ประกอบของบริการไม่ได้เป็นส่วนหนึ่งของรหัสบริการ ใน OO วัตถุสร้างวัตถุอื่น ๆ ดังนั้นจึงไม่จำเป็นต้องมีสิ่งอำนวยความสะดวกดังกล่าว แต่สำหรับ SO นั้นเป็นเพราะบริการไม่ได้ยกตัวอย่างหรือกำหนดค่าบริการอื่น ๆ
• พวกเขาสร้างเอฟเฟ็กต์ภายในแพลตฟอร์มที่ด้านบนของ OO (EJB ต้น, CORBA) ที่โปรแกรมเมอร์ต้องเขียนโค้ดทั้งหมดที่จำเป็นในการ "ขับ" ดังนั้น คลาสแสดงถึงส่วนหนึ่งของธรรมชาติของบริการเท่านั้นและจะต้องเขียนคลาสจำนวนมากเพื่อสร้างบริการด้วยกัน จานหม้อไอน้ำทั้งหมดนั้นเป็นสิ่งจำเป็นเพราะไม่มีคอมไพเลอร์ SO ซึ่งจะทำเพื่อโปรแกรมเมอร์ นี่เป็นเหมือนบางคนทำใน C สำหรับ OO เมื่อไม่มี C ++ คุณเพิ่งผ่านการบันทึกซึ่งเก็บข้อมูลของวัตถุเป็นพารามิเตอร์แรกไปยังขั้นตอนซึ่งเป็นวิธีการ ในภาษา OO พารามิเตอร์นี้มีความหมายโดยนัยและคอมไพเลอร์สร้างโค้ดทั้งหมดที่เราต้องการสำหรับฟังก์ชั่นเสมือนเป็นต้นสำหรับ SO นี่จะหายไปอย่างชัดเจน
• โดยเฉพาะอย่างยิ่งเฟรมเวิร์กที่ใหม่กว่านั้นใช้ AOP หรือวิปัสสนาเพื่อเพิ่มส่วนที่ขาดหายไปในภาษา OO สิ่งนี้ไม่นำมาซึ่งการใช้ภาษาที่จำเป็น แต่หลีกเลี่ยงรหัสแพลตฟอร์มของหม้อไอน้ำที่อธิบายไว้ในจุดก่อนหน้า
• เฟรมเวิร์กบางตัวใช้การสร้างรหัสเพื่อสร้างรหัสแผ่นบอยเลอร์ ไฟล์การกำหนดค่าใน XML หรือคำอธิบายประกอบในรหัส OO เป็นแหล่งข้อมูลสำหรับสิ่งนี้

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

เพราะ <5% ของรหัสกำลังกำหนดเซอร์วิสอยู่และฉันจะเถียงเวลาน้อยกว่านี้มาก เมื่อมีการกำหนดอินเทอร์เฟซก็จะทำส่วนใหญ่ เวลาที่เหลืออยู่ใน OO (หรือทางเลือก) ทำให้สิ่งต่างๆทำงานได้

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

[แก้ไขสำหรับการชี้แจง OPs ว่าเป็นรูปแบบแอปพลิเคชันภายในไม่ใช่ขอบเขตแอปพลิเคชัน]:

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

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

ภาษาอื่น ๆ เช่น Scala, Clojure และ F # ยังให้ความหมายของ "เชิงบริการ" ปัญหาไม่ได้อยู่ที่พวกเขาไม่มีอยู่นั่นคือประชาชนทั่วไปกลัวพวกเขาดังนั้นพวกเขาจึงไม่เป็นที่นิยม

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

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

อย่างไรก็ตามมีภาษาหนึ่งประเภทที่แนะนำคือภาษาคำจำกัดความของบริการบนเว็บ WSDL เป็นภาษาเมตาของ SOA (และมีอีกอันที่ถูกทอดทิ้งสำหรับ REST ชื่อ WADL)

ฉันจะเปลี่ยนคำถามและถามว่า "ภาษา SO จะเป็นอย่างไร?"

สัญญาเหล่านั้นระหว่างโมดูลจะถูกเขียนอย่างไร
กลไกพื้นฐานของการปฏิบัติการจะถูกประหารชีวิตอย่างไร?

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

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

Great Q และให้ช่วงเวลาที่ดีแก่ฉัน

ฉันจะเสนอคำตอบสำหรับคำถามของฉันเองเพื่อดูว่ามีกี่คนที่เห็นด้วยและไม่เห็นด้วย

ความเป็นไปได้บางอย่าง:

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

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

  1. ฟังก์ชั่นไปที่ชั้นเรียนที่ข้อมูลตั้งอยู่ที่พวกเขาทำงาน รหัสและข้อมูลจะถูกรวมเข้าด้วยกันในโมดูลเดียวกัน ไม่ใช่สไตล์ OO ที่จะมีคลาสแยกต่างหากที่ทำงานกับข้อมูลของคลาสอื่น ๆ นั่นเป็นแนวทางของเครื่องมือและวัสดุ (WAM) ของZüllighofenซึ่งตรงกับกระบวนทัศน์ของ SO

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

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

  1. หลักการพึ่งพา - การผกผันใน OO นั้นคล้ายคลึงกับวิธีการบริการที่ประกอบขึ้นจากภายนอก

  2. วัตถุ Singleton เหมือนบริการโรงงานวัตถุก็เหมือนบริการที่ตั้ง

  3. OO ยังมีส่วนต่อประสานที่คล้ายกับส่วนต่อประสานบริการ

  4. การสืบทอดของคลาสสามารถคล้ายกัน (เหมือนกัน) เป็นมรดกของการบริการและบันทึก

• OO และ SO นั้นมีประโยชน์สำหรับปัญหาประเภทต่างๆ ดังนั้นในทุก ๆ แอปพลิเคชั่นมันเป็นการดึงดูดให้ใช้กระบวนทัศน์ทั้งที่นี่หรือที่นั่น การมีภาษาแยกต่างหากจะขัดขวางการสลับระหว่างสองภาษาภายในโปรแกรมเดียวกัน

• SO ไม่ได้เป็นเพียงแค่กระบวนทัศน์การเขียนโปรแกรม แต่ยังรวมถึงพฤติกรรมของโปรแกรม: บริการบนเว็บ, ส่วนประกอบของระบบปฏิบัติการ ฯลฯ นั้นเป็น SO แต่ไม่จำเป็นต้องเขียนด้วยภาษา SO "ส่วนประกอบไบนารี" ชนิดนี้เป็นธรรมชาติและประสบความสำเร็จมาก แต่มันเป็นสิ่งที่ต่างออกไป: มันเป็นวิธีที่โปรแกรมสื่อสารกันไม่ใช่วิธีที่โปรแกรมสื่อสารภายใน ฉันเดาว่าคนผสมกันบ่อยครั้งมากพอ