การเขียนโปรแกรมเชิงบริการ ( Service-oriented programmingหรือ SOP) เป็นกระบวนทัศน์การเขียนโปรแกรมที่ใช้ "บริการ" เป็นหน่วยการทำงานของคอมพิวเตอร์ เพื่อออกแบบและใช้งานแอปพลิเคชันทางธุรกิจแบบบูรณาการ และ โปรแกรมซอฟต์แวร์ที่สำคัญต่อภารกิจ บริการสามารถแทนขั้นตอนของกระบวนการทางธุรกิจดังนั้นหนึ่งในแอปพลิเคชันหลักของกระบวนทัศน์นี้คือการส่งมอบแอปพลิเคชันทางธุรกิจแบบสแตนด์อโลนหรือแบบผสมที่สามารถ "บูรณาการจากภายในสู่ภายนอก" ได้อย่างคุ้มค่า โดยพื้นฐานแล้วมันส่งเสริมสถาปัตยกรรมเชิงบริการ (Service-oriented architectureหรือ SOA) อย่างไรก็ตาม มันไม่เหมือนกับ SOA ในขณะที่ SOA มุ่งเน้นไปที่การสื่อสารระหว่างระบบโดยใช้ "บริการ" ^{[ 1 ]} SOP นำเสนอเทคนิคใหม่ในการสร้างโมดูล แอปพลิเคชันที่คล่องตัว โดยใช้บริการในหน่วยความจำเป็นหน่วยการทำงาน

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

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

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

แนวคิด SOP เป็นพื้นฐานที่แข็งแกร่งสำหรับแนวทางเชิงความหมายในการบูรณาการการเขียนโปรแกรมและตรรกะของแอปพลิเคชัน แนวทางนี้มีข้อดีที่สำคัญสามประการ:

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

ต่อไปนี้คือแนวคิดหลักบางประการของ SOP:

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

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

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

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

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

ใน SOP โมดูลบริการสามารถนำไปใช้ได้ทั้งในรูปแบบบริการแบบผสม (Composite service) หรือบริการแบบอะตอมิก (Atomic service) สิ่งสำคัญที่ควรทราบคือ โมดูลบริการที่สร้างขึ้นตามแบบแผน SOP มีลักษณะที่เปิดเผยต่อภายนอก และสามารถถ่ายทอดออกไปภายนอกได้อย่างโปร่งใสผ่านมาตรฐานต่างๆ เช่นSOAP หรือโปรโตคอลที่เป็นกรรมสิทธิ์ ใดๆ ก็ได้

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

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

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

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

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

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

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

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

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

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

บริการอะตอมิก (Atomic Service) คือส่วนขยายในหน่วยความจำของสภาพแวดล้อมการทำงานของ SOP ผ่านทางอินเทอร์เฟซดั้งเดิมของบริการ (Service Native Interface หรือ SNI) โดยพื้นฐานแล้วมันคือกลไกปลั๊กอิน ตัวอย่างเช่น หาก SOP ถูกทำให้เป็นอัตโนมัติผ่านSVMปลั๊กอินบริการจะถูกโหลดเข้าไปใน SVM แบบไดนามิกเมื่อมีการใช้งานบริการที่เกี่ยวข้อง ตัวอย่างของปลั๊กอินบริการคือ ปลั๊กอินตัวสื่อสาร SOAPที่สามารถแปลงข้อมูลอินพุตของบริการในหน่วยความจำให้เป็นคำขอ SOAP ของเว็บเซอร์วิสแบบเรียลไทม์ ส่งไปยังผู้ผลิตบริการ และจากนั้นแปลงการตอบกลับ SOAP ที่เกี่ยวข้องให้เป็นข้อมูลเอาต์พุตในหน่วยความจำบนบริการ อีกตัวอย่างหนึ่งของปลั๊กอินบริการคือปลั๊กอิน SQL ฐานข้อมูลมาตรฐานที่รองรับการเข้าถึง การแก้ไข และการดำเนินการสืบค้นข้อมูล ตัวอย่างเพิ่มเติมที่ช่วยให้เห็นถึงความสำคัญพื้นฐานของบริการอะตอมิกและปลั๊กอินบริการคือการใช้ตัวเรียกใช้บริการ (Service Invoker) เป็นปลั๊กอินบริการเพื่อจำลองบริการอย่างโปร่งใสในอินสแตนซ์ต่างๆ ของแพลตฟอร์ม SOP การจำลองเสมือนระดับส่วนประกอบที่เป็นเอกลักษณ์นี้เรียกว่า "การจำลองเสมือนแบบกริดบริการ" เพื่อให้แตกต่างจากการจำลองเสมือน ระดับแอปพลิเคชันหรือระดับกระบวนการ แบบ ดั้งเดิม

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

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

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

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

นอกเหนือจากความสามารถในการเรียกใช้บริการใดๆ แล้ว เหตุการณ์การร้องขอการบริการ (Service Request Events) และหน่วยความจำที่ใช้ร่วมกัน (Shared Memory) เป็นกลไกในตัวของ SOP สองอย่างที่ใช้สำหรับการสื่อสารระหว่างบริการ การใช้งานบริการจะถูกมองว่าเป็นเหตุการณ์ใน SOP SOP มีกลไกเหตุการณ์แบบอิงความสัมพันธ์ ซึ่งส่งผลให้การทำงานของคอมโพสิตที่ประกาศความต้องการรอให้เหตุการณ์การใช้งานบริการอื่นๆ อย่างน้อยหนึ่งเหตุการณ์เกิดขึ้นพร้อมกับค่าข้อมูลอินพุตที่ระบุไว้ ผ่านโครงสร้าง "wait" ถูกขัดจังหวะ การทำงานของบริการคอมโพสิตจะดำเนินต่อไปเมื่อมีการใช้งานบริการด้วยอินพุตคีย์ความสัมพันธ์เฉพาะที่เกี่ยวข้องกับโครงสร้าง wait SOP ยังมี พื้นที่ หน่วยความจำที่ใช้ร่วมกัน พร้อมการควบคุมการเข้าถึง ซึ่งบริการสามารถเข้าถึงและอัปเดต โครงสร้างข้อมูลที่กำหนดไว้อย่างดีซึ่งคล้ายกับโครงสร้างอินพุต/เอาต์พุตของบริการ กลไกหน่วยความจำที่ใช้ร่วมกันภายใน SOP สามารถเข้าถึงได้โดยทางโปรแกรมผ่านอินเทอร์เฟซของบริการ

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

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

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

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

คำว่า " การเขียนโปรแกรมเชิงบริการ" (Service-Oriented Programming หรือ SOP)ถูกตีพิมพ์ครั้งแรกในปี 2545 โดย Alberto Sillitti, Tullio Vernazza และ Giancarlo Succi ในหนังสือชื่อ "Software Reuse: Methods, Techniques, and Tools" SOP ดังที่กล่าวมาข้างต้น สะท้อนให้เห็นถึงบางแง่มุมของการใช้คำนี้ตามที่ Sillitti, Vernazza และ Succi เสนอไว้

ปัจจุบัน รูปแบบ SOP ยังอยู่ในช่วงเริ่มต้นของการนำไปใช้ในวงกว้าง โดยมีปัจจัยขับเคลื่อนตลาดสี่ประการที่ผลักดันการนำไปใช้นี้:

• สถาปัตยกรรมโปรเซสเซอร์ แบบมัลติคอร์ : เนื่องจากปัญหาการระบายความร้อนที่เกิดจากความเร็วสัญญาณนาฬิกาของโปรเซสเซอร์ที่เพิ่มขึ้นเกิน 4 GHz ผู้ผลิตโปรเซสเซอร์ชั้นนำอย่างIntelจึงหันมาใช้สถาปัตยกรรมแบบมัลติคอร์เพื่อมอบประสิทธิภาพที่เพิ่มขึ้นอย่างต่อเนื่อง โปรดดูบทความ "The Free Lunch Is Over " การเปลี่ยนแปลงการออกแบบนี้บังคับให้เราต้องเปลี่ยนแปลงวิธีการพัฒนาโมดูลซอฟต์แวร์และแอปพลิเคชันของเรา แอปพลิเคชันต้องเขียนขึ้นเพื่อ รองรับการทำงาน พร้อมกันเพื่อใช้ประโยชน์ จากโปรเซสเซอร์ แบบมัลติคอร์และการเขียนโปรแกรมแบบพร้อมกันนั้นเป็นงานที่ท้าทาย SOP ให้โอกาสในการสร้างมัลติเธรด แบบอัตโนมัติ ใน ตัว
• การจำลองเสมือนแอป พลิเคชัน : SOP ส่งเสริมการควบคุมระดับไมโครในตัวเกี่ยวกับการเปิดเผยตำแหน่งที่ตั้งของส่วนประกอบบริการของโมดูลบริการใดๆ ส่งผลให้เกิดการจำลองเสมือนส่วนประกอบแอปพลิเคชันโดยอัตโนมัติและละเอียด (แทนที่จะเป็นกระบวนการแอปพลิเคชันทั้งหมด) บนคลัสเตอร์หรือกริดของแพลตฟอร์มรันไทม์ SOP
• สถาปัตยกรรมเชิงบริการ (Service-Oriented Architectureหรือ SOA) และความต้องการแอปพลิเคชันแบบบูรณาการและแบบผสมผสาน: ในช่วงเริ่มต้น การนำ SOP มาใช้จะตามเส้นโค้งการนำ SOA มาใช้โดยมีความล่าช้าเล็กน้อย เนื่องจากบริการที่สร้างขึ้นผ่าน SOA สามารถประกอบและใช้งานได้ง่ายผ่าน SOP ยิ่งเว็บเซอร์วิสแพร่หลายมากขึ้นเท่าใด การใช้ประโยชน์จากลักษณะเชิงความหมายของ SOP ก็ยิ่งมีความหมายมากขึ้นเท่านั้น ในทางกลับกัน เนื่องจาก SOA เป็นส่วนหนึ่งของ SOP อยู่แล้ว SOP จึงเป็นวิธีที่คุ้มค่าในการนำ SOA ไปสู่ตลาดหลัก
• ซอฟต์แวร์เป็นบริการ (SaaS): ความสามารถของแพลตฟอร์ม SaaS ในปัจจุบันไม่สามารถตอบสนองความซับซ้อนของการปรับแต่งและการบูรณาการที่องค์กรขนาดใหญ่ต้องการได้ SOP สามารถลดความซับซ้อนของการบูรณาการและการปรับแต่งได้อย่างมาก ซึ่งจะผลักดันให้ SOP ก้าวเข้าสู่แพลตฟอร์ม SaaS รุ่นต่อไป

• ไมโครเซอร์วิส

• การเขียนโปรแกรมเชิงบริการ: รูปแบบใหม่ของการนำซอฟต์แวร์กลับมาใช้ใหม่
• การจำลองเสมือนแบบกริดและโซลูชันที่ใช้ Itanium®