In a general reply ( to why WoW ( chose Applet over AJAX, I starts to think a new idea about how mass software componets are being integrated nowadays, and get some new thoughts. Briefly, I found in a common sense APIs (Application Programming Interface) are *monolayered*, even the Service Definitions in the SOA approach. I use *monolayered* to mean that they are a list of methods/functions designed to be invoked. But the functionalities of Software Components today and logics to use them are rather complicated, and mostly *multi-dimensional* - structual objects and structual logics. So the necessary effort to compact/abstract multi-dimensional logics in to monolayered public interfaces rises quickly. In many cases, the interface abstraction work and effort needed to produce good specifications for the sets of APIs get even more costly than the problem/solution itself. So I began doubting if the way to define Software Components' behaviors as public interfaces/services is still the best, and unavoidable necessary. I name this approache as Invocation Based Interfacing, under which you always invoke to change a target component's states or get result from the component. I then summarized an opposing approach, I named Hosting Based Interfacing. In this approach, Task Agents are transmitted between software components, to perform their desitinated duties. What's changed is that software components never have to define public (services) interfaces for repeatedly call-return rounds, instead, they publish local environments (can just simply export part of their internal logics as public, in their straight logics), to *host* Task Agents on receipt. So various Task Agents can use environments provided by their target component to accomplish their work and send results back as new Task Agents if necessary. The raw idea has arised in my design of the Traverser/Scener Architecture ( for WoW. But now I see it a little clearer. What do you think of this? - Compl ( - Programming By Nature)