Synchrony abstraction
It is proposed that this article be deleted because of the following concern:
If you can address this concern by improving, copyediting, sourcing, renaming, or merging the page, please edit this page and do so. You may remove this message if you improve the article or otherwise object to deletion for any reason. Although not required, you are encouraged to explain why you object to the deletion, either in your edit summary or on the talk page. If this template is removed, do not replace it. The article may be deleted if this message remains in place for seven days, i.e., after 06:26, 5 August 2025 (UTC). Find sources: "Synchrony abstraction" – news · newspapers · books · scholar · JSTOR |
Abstraction of synchrony is the proposed ability to generically call a service or operation without regard to whether the target service is configured as a synchronous or asynchronous protocol. The user may then call all services and expect a reply which may be utilized generically.
This architectural abstraction is made necessary due to functional logic abstraction, which is the capability of separating business logic implementation code from the service protocol implementation calling it. The fact that business logic implementations (operations) may be implemented in synchronous or asynchronous manners and that these business logic implementations may be interchangeable can cause problems when not addressed.
Sources
[edit]- elemenope User Guide