事務語義和狀態滿度在EJB3中被視爲實現細節。 實現可以決定是使用bean還是容器管理的事務。 它可以決定容器管理事務的類型。它可以決定它是滿狀態還是無狀態。EJB3：爲什麼事務語義和狀態性會考慮實現細節？
但從邏輯上講，這些是重要的接口細節。例如：（a）使用bean管理事務的bean不能使用容器管理事務調用bean。 （b）無狀態bean不能調用狀態滿bean。
當提供一個EJB3接口時，你不知道它需要什麼樣的事務語義。同樣，你也不知道它是否是全狀態或無狀態的。 您需要額外的實施細節。例如：文檔。
在運行時，可以動態實例化不同的bean和調用鏈。因此可能會出現無效狀態。現在 - 容器可以捕捉這些情況;但爲什麼要等到運行時？
爲什麼事務語義和狀態滿度要求不是界面的一部分？
交易語義和 狀態充滿度被認爲是 EJB3中的實現細節。一個 實現可以決定是否使用bean或容器管理 事務。它可以決定容器管理事務的類型 。 它可以決定它是否爲全狀態 或無狀態。
我明白狀態管理這點從客戶的角度來看確實很重要。
關於交易，這有點棘手。
bean-managed或container-managed）的類型爲實現細節（我不知道你的例子（一））。required,mandatory,none等）。現在 - 容器可以捕獲這些 的情況;但爲什麼要等到 運行時？
即使所有這是本與一個接口，所述類型系統仍然不足以執行在編譯類型的規則。
無論如何，你需要一個工具來檢查這些約束，根據它們的應用語義。如果解析註釋，IDE可以做到這一點，容器可以在模塊部署時執行它，更糟的是它在運行時失敗。
爲什麼事務語義和 狀態，豐滿的要求不是接口的一部分 ？
一個java 接口僅攜帶一組有限的有關組件的正確用法的信息，可以是一個類，和豆，或API。大多數組件的合同合同比接口中暴露的要複雜得多。
例子：
ContentHandler.characters()：你怎麼知道它可以被稱爲每個XML標籤不止一次？我個人使用合同術語指完成設置限制。 接口從類型系統的角度給我只給出了方法的簽名。
如果您對該主題感興趣，我建議您看看design by contract。更準確地確定組件之間合同的想法已經存在了很長時間。
所以我的答案是：因爲即使它是，你仍然需要更多的信息。