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

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

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

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

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

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

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

การเขียนโปรแกรมแบบขับเคลื่อนด้วยเหตุการณ์ (Event-Driven Programmingหรือ SOA 2.0) มีโครงสร้างอยู่บนแนวคิดของความสัมพันธ์ที่แยกส่วนกันระหว่างผู้สร้างเหตุการณ์และผู้บริโภคเหตุการณ์: ผู้บริโภคเหตุการณ์ไม่สนใจว่าเหตุการณ์จะเกิดขึ้นที่ไหนหรือเพราะเหตุใด แต่จะสนใจว่าตนเองจะถูกเรียกใช้งานเมื่อเหตุการณ์เกิดขึ้นแล้ว ระบบและแอปพลิเคชันที่แยกผู้สร้างเหตุการณ์ออกจากผู้บริโภคเหตุการณ์มักจะอาศัยตัวจัดการเหตุการณ์ (Event Dispatcher) หรือช่องทาง (Channel) ช่องทางนี้ประกอบด้วยคิวเหตุการณ์ (Event Queue) ซึ่งทำหน้าที่เป็นตัวกลางระหว่างผู้สร้างเหตุการณ์และตัวจัดการเหตุการณ์ (Event Handler)

รูปแบบ SOA 2.0 ต้นแบบประกอบด้วยองค์ประกอบสำคัญสี่ประการ:

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

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

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

BPELใช้รูปแบบการจัดการแบบออร์เคสเตรชัน ส่วนการจัดลำดับการทำงานนั้นครอบคลุมโดยมาตรฐานอื่นๆ เช่น WSCI (Web Services Choreography Interface)และWS-CDL (Web Services Choreography Description Language)

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

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

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

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

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

นักวิเคราะห์ธุรกิจสามารถเพิ่มรายละเอียดเพิ่มเติมได้โดยใช้คำสั่ง SQL ที่แนบมากับบริบทของกฎหรือเหตุการณ์ แอปพลิเคชัน CVE ทำงานคล้ายกับแอปพลิเคชันการซื้อขายหุ้นในปัจจุบันที่ผู้จัดการกองทุนรวมใช้ในการจัดการความเสี่ยง ตัวอย่างของแอปพลิเคชันและกลไก CVE สามารถดูได้ใน SILK ^{[ 2 ]}

การใช้งาน Enterprise Service Bus (ESB) ส่วนใหญ่มีฟังก์ชันที่เรียกว่า " การไกล่เกลี่ย " ตัวอย่างเช่น โฟลว์การไกล่เกลี่ยเป็นส่วนหนึ่งของการดักจับEnterprise Service Bus ของ WebSphere Muleก็รองรับโฟลว์การไกล่เกลี่ยเช่นกัน โฟลว์การไกล่เกลี่ยจะแก้ไขข้อความที่ส่งผ่านระหว่างบริการที่มีอยู่และไคลเอ็นต์ที่ใช้บริการเหล่านั้น โฟลว์การไกล่เกลี่ยจะทำหน้าที่ไกล่เกลี่ยหรือแทรกแซงเพื่อให้ฟังก์ชันต่างๆ เช่น การบันทึกข้อความ การแปลงข้อมูล และการกำหนดเส้นทาง โดยทั่วไปฟังก์ชันเหล่านี้สามารถนำไปใช้ได้โดยใช้รูปแบบการออกแบบการดักจับ^{[ 3 ]}

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

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

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

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

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

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

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

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

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

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

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

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

กลไกหนึ่งที่สามารถนำมาใช้ได้จากระบบEnterprise Service Bus ( ESB) ที่ใช้ SOA 1.0 ส่วนใหญ่ คือ ฟังก์ชันการ เผยแพร่/สมัครรับข้อมูล (publish/subscribe ) โดยการนำฟังก์ชัน ESB มาใช้ในรูปแบบข้อความ Pub/Sub ทำให้ไม่จำเป็นต้องมีความรู้ขั้นสูงเกี่ยวกับเหตุการณ์ของระบบในการสร้างรูปแบบข้อความ SOA 2.0 หลังจากที่องค์กรได้นำฟังก์ชันการเผยแพร่มาใช้แล้ว นักวิเคราะห์มิดเดิลแวร์ SOA สามารถเริ่มวางแผนกลยุทธ์ว่าข้อความเผยแพร่ใดบ้างที่สามารถนำมาประกอบกันเป็นรูปแบบเฉพาะเพื่อตรวจจับทริกเกอร์ที่ได้รับการปรับปรุงด้วย SOA 2.0 ได้

กลไกของ Causal Vector Engine (CVE) ถูกนำมาใช้อย่างง่าย ๆ โดยมีมุมมองที่ขยายได้ของโครงสร้าง SQLที่เขียนไว้ในstored procedure [ ^{4 ] หาก} A เป็นสาเหตุของBและความเป็นเหตุเป็นผลต้องเกิดขึ้นภายในจำนวนธุรกรรมN แล้ว คำสั่ง SQL ORDER BY timestampจะสร้างชุดผลลัพธ์ที่เพิ่มตัวนับของธุรกรรมทั้งหมดที่เกิดขึ้นภายในกรอบเวลาNจำนวนธุรกรรมที่ตรงกับBต่อเหตุการณ์Aการสร้าง stored procedure เพิ่มเติมทำได้ผ่านแอปพลิเคชันคอนโซล CVE หรือโดยใช้ชุดเครื่องมือสำหรับนักพัฒนาฐานข้อมูลมาตรฐานใด ๆ^{[ 5 ]}

อัลกอริทึมโดเมน เช่น ตรรกะโดเมนไข้/ไข้หวัดใหญ่/การติดเชื้อในเอกสารอ้างอิงที่อ้างถึง ถูกนำมาใช้เพื่อสร้างโค้ด SQL ที่ใช้กฎทางธุรกิจที่เลือกกับกรณีการใช้งาน การใช้ CVE ในสภาพแวดล้อม SOA ช่วยปรับปรุงความคล่องตัวทางธุรกิจ เนื่องจากการประยุกต์ใช้หลักการ SOA 2.0 ช่วยระบุโอกาสทางธุรกิจที่อาจพลาดไปหรือระบุได้ช้ากว่ามาก^{[ 6 ]}

การถ่ายภาพด้วยคลื่นแม่เหล็กไฟฟ้าเชิงฟังก์ชัน (fMRI) โดยใช้การวิเคราะห์ความสัมพันธ์เชิงสาเหตุแบบ Granger (GCA) ตรวจจับผลกระทบเชิงสาเหตุระหว่างบริเวณสมอง ผลลัพธ์ของการทดสอบตัวอย่างหนึ่งตัวอย่างแสดงให้เห็นผลกระทบเชิงสาเหตุเชิงบวกระหว่าง rFIC และคอร์เทกซ์ซิงกูเลตด้านหน้าส่วนหลัง (dACC) ^{[ 7 ]}

Oracle CVE Analytical Engineใช้ชุดแบบจำลองเชิงทฤษฎี ซึ่งแต่ละแบบจำลองจะประเมินข้อมูลบางส่วนหรือทั้งหมด เมื่อนักวิเคราะห์ธุรกิจกำหนดค่าปัจจัยเชิงสาเหตุ เขา/เธอจะระบุเกณฑ์ที่บ่งชี้ว่าแบบจำลองใดควรพิจารณาปัจจัยเชิงสาเหตุใด^{[ 8 ]}

• สถาปัตยกรรมที่เน้นการบริการ
• ภาษามาร์กอัปแมชอัพระดับองค์กร (EMML)