Really? Declarative Transactions?!? (จริงหรือ? Declarative Transaction?!?)

ใช่ จริง ๆ หนึ่งใน “feature” ของ application server หลายตัวในยุครุ่งเรืองของ orchestration-driven SOA คือการอนุญาตให้ configuration manager เปลี่ยน transactional scope ของ entity แต่ละตัวได้ ขึ้นอยู่ กับ transactional context ที่พวกเขาต้องการให้ทำงาน (แน่นอนว่าสิ่งนี้ถูกประกาศไว้ใน XML ตามยุคสมัยที่ ชื่นชอบ configuration format ที่ยืดยาวแต่ parse ง่าย) ส่วนหนึ่งของการประกาศ entity (เรียกว่า EntityBeans ซึ่งเป็น JavaBean ประเภทพิเศษ) จะกำหนด transactional scope เมื่อมันเข้าร่วมใน workflow ซึ่งสถาปนิก เองเป็นผู้ประกาศว่าจะเป็น transactional หรือไม่ จากนั้น application server จะโต้ตอบกับฐานข้อมูลเพื่อ สร้างและจัดการ database transaction ที่ตรงกับพฤติกรรมที่ต้องการของ entity และ/หรือ workflow

สิ่งนี้ล้มเหลวเป็นส่วนใหญ่ ด้วยสองเหตุผล ประการแรก ถ้า developer ไม่รู้ว่า transactional behavior จะเป็นอย่างไรตอน runtime มันจะเพิ่มความซับซ้อนอย่างมากให้กับ entity และ dependency สิ่งนี้บังคับให้ developer ต้องสร้าง entity เวอร์ชันที่แทบจะเหมือนกันทุกประการ ต่างกันแค่ transactional scope ประการที่สอง ไม่ว่า vendor จะใส่ความซับซ้อนเข้าไปใน message bus ของตัวเองมากแค่ไหน edge case ก็ยัง ปรากฏขึ้นเรื่อย ๆ ในจุดที่ failure mode มากมายขัดขวางไม่ให้ระบบจัดการ transaction ได้อย่างเรียบร้อย สร้างความยุ่งเหยิงของความไม่สอดคล้องกันให้มนุษย์ต้องมาแก้ไข feature บางอย่างของระบบที่ซับซ้อนและมี หลายมิติ (เช่น transaction) ไม่สามารถถูก abstract ออกไปได้อย่างสะอาดหมดจด การรั่วไหลของ abstraction ที่มากเกินไปทำให้มันไม่สามารถบรรลุ reliability ได้