HBI（Hosting-Based Interfacing）是一种用于提高分布式应用程序间互操作性的架构，它通过让软件组件在其本地环境中执行来自对等方的逻辑来实现资源的高效利用和事务的透明重试。与传统的同步访问远程资源的方法相比，HBI能够显著提升性能并减少因同步执行和分布式数据缓存带来的问题。
[b]HBI - Hosting Based Interfacing [/b]
[b]What is (not) HBI? [/b]
[quote]HBI is about interoperability among distributed applications (software components), built with same or different technologies. As the name implies, HBI is an architecture that software components communicate with each others by hosting the execution of logics from peers. HBI is to get rid of synchronous access to remote resources, make all code executed natively and locally (in both concept and practice) whereas asynchronously. So transactional logics can be naturally grouped into atomic units and performed in parallel ways. On optimistic commit failures, transactions are possible to be retried automatically and transparently. At the same time performance drop and pitfalls due to synchronous execution and distributed data cache are get rid of, as well.
SQL is essentially semi-HBI: There is an interesting fact that wherever you wrote your SQL code, it is executed in the server environment, and you know your SQL always access local resources like tables, views and stored-procedures etc. SQL transactions naturally consist of arbitrary statements between two COMMITs. Pure SQL transactions are possible to be transparently retried on optimistic commit failures.
On the contrary is IBI - Invocation Based Interfacing. Those paradigms try to hide resources behind some mechanisms so that access to resources are wrapped/encapsulated in synchronous ways, regardless they are local or remote. Some define service invocation interfaces, like RMI (including EJB), Web-Service, where remote routines encapsulate their resources and are wrapped like client-local code. Some allow data resources distributed to client environment and wrapped with client-local library code that transparently make data available, handle validity, and manage consistency, like various OODBs, ORM. Transactions can rarely be transparently retried on these infrastructures. [/quote]
[b]What does HBI cost? [/b]
[quote]Distribution and concurrency/parallel become explicit, asynchronous complexity instead of implicit, synchronous complexity.
Synchronous programming habit will be broken, programmers will have to consciously know that some blocks of their code will run asynchronously at environments (domains) other than the local application they are developing. Code relies on the result of some remote manipulations can not be programmed as a subsequent block of that manipulation code, but must be implemented as local task agent objects that the remote peer can send back to indicate the result.
Higher security profile. Applications need to enforce sandboxes to host executions of objects from other domains, against malfunctioning peers and hostile attacks. [/quote]
[b]What HBI benefits? [/b]
[quote]The architecture of large RAM/storage shared by many CPUs/cores is best benefited. Large data sets in a single memory space and local storage are shared as-is to all domains requiring them, manipulations to these resources are hosted by local CPUs/cores having direct access to them. This is the most efficient way for distributed domain resource sharing.
As a result, performance is a biggest hit. All data and logics become local and native, and can be greatly optimized with explicit parallel (parallel candidates are expressed by application code as a side effect). No data replicated anymore, large amount of redundant memory and bandwidth saved.
Much less pitfalls due to distribution of objects. Neither objects are distributed anymore, nor do they need to be transfered over wire, objects now always identify themselves at where they actually are, no shadow copies or stubs or proxies used to create subtle errors and harden debugging.
Server applications are much more stable. Most new client requirements those used to need service API changes in traditional approaches now can be unilaterally achieved by modifying only the client application.
Client applications can go much richer without resistance from the server side, do not need to change/restart server applications (i.e. less permissions/efforts required) in order to evolve client applications.
Client applications have their own rich domain models that focus on their own functionalities, much better separated from functionalities like persistence and work flows those server applications need to care. Client applications can focus on their own domain model which is regarded by server applications by translating server domain model changes to client behaviors through delivery of task agent life scripts.
More effective Object Orientation. No data packet based protocol anymore, all logics become behaviors of either domain objects or agent objects triggered by task agent life script.
P2P communications become more natural. Clients are also domains, they are at the same priority of server components in inter-domain communications.
Much more realtime-interactive features can be naturally implemented to enhance user experience. Built-in server-push and P2P-push ability well enable it. [/quote]
[b]What is (not) HBI? [/b]
[quote]HBI is about interoperability among distributed applications (software components), built with same or different technologies. As the name implies, HBI is an architecture that software components communicate with each others by hosting the execution of logics from peers. HBI is to get rid of synchronous access to remote resources, make all code executed natively and locally (in both concept and practice) whereas asynchronously. So transactional logics can be naturally grouped into atomic units and performed in parallel ways. On optimistic commit failures, transactions are possible to be retried automatically and transparently. At the same time performance drop and pitfalls due to synchronous execution and distributed data cache are get rid of, as well.
SQL is essentially semi-HBI: There is an interesting fact that wherever you wrote your SQL code, it is executed in the server environment, and you know your SQL always access local resources like tables, views and stored-procedures etc. SQL transactions naturally consist of arbitrary statements between two COMMITs. Pure SQL transactions are possible to be transparently retried on optimistic commit failures.
On the contrary is IBI - Invocation Based Interfacing. Those paradigms try to hide resources behind some mechanisms so that access to resources are wrapped/encapsulated in synchronous ways, regardless they are local or remote. Some define service invocation interfaces, like RMI (including EJB), Web-Service, where remote routines encapsulate their resources and are wrapped like client-local code. Some allow data resources distributed to client environment and wrapped with client-local library code that transparently make data available, handle validity, and manage consistency, like various OODBs, ORM. Transactions can rarely be transparently retried on these infrastructures. [/quote]
[b]What does HBI cost? [/b]
[quote]Distribution and concurrency/parallel become explicit, asynchronous complexity instead of implicit, synchronous complexity.
Synchronous programming habit will be broken, programmers will have to consciously know that some blocks of their code will run asynchronously at environments (domains) other than the local application they are developing. Code relies on the result of some remote manipulations can not be programmed as a subsequent block of that manipulation code, but must be implemented as local task agent objects that the remote peer can send back to indicate the result.
Higher security profile. Applications need to enforce sandboxes to host executions of objects from other domains, against malfunctioning peers and hostile attacks. [/quote]
[b]What HBI benefits? [/b]
[quote]The architecture of large RAM/storage shared by many CPUs/cores is best benefited. Large data sets in a single memory space and local storage are shared as-is to all domains requiring them, manipulations to these resources are hosted by local CPUs/cores having direct access to them. This is the most efficient way for distributed domain resource sharing.
As a result, performance is a biggest hit. All data and logics become local and native, and can be greatly optimized with explicit parallel (parallel candidates are expressed by application code as a side effect). No data replicated anymore, large amount of redundant memory and bandwidth saved.
Much less pitfalls due to distribution of objects. Neither objects are distributed anymore, nor do they need to be transfered over wire, objects now always identify themselves at where they actually are, no shadow copies or stubs or proxies used to create subtle errors and harden debugging.
Server applications are much more stable. Most new client requirements those used to need service API changes in traditional approaches now can be unilaterally achieved by modifying only the client application.
Client applications can go much richer without resistance from the server side, do not need to change/restart server applications (i.e. less permissions/efforts required) in order to evolve client applications.
Client applications have their own rich domain models that focus on their own functionalities, much better separated from functionalities like persistence and work flows those server applications need to care. Client applications can focus on their own domain model which is regarded by server applications by translating server domain model changes to client behaviors through delivery of task agent life scripts.
More effective Object Orientation. No data packet based protocol anymore, all logics become behaviors of either domain objects or agent objects triggered by task agent life script.
P2P communications become more natural. Clients are also domains, they are at the same priority of server components in inter-domain communications.
Much more realtime-interactive features can be naturally implemented to enhance user experience. Built-in server-push and P2P-push ability well enable it. [/quote]
扫一扫
2816
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
