> From: Shekhar Jha [mailto:[EMAIL PROTECTED]] > > Thanks for > That solves the problem of the component generation ( even > though in this scenario the container has to be aware of the > distributed nature of the component and the protocol to > generate the proxy??) Let us take an example of a cache > implementation that provides the facility of synchronization > accross multiple server instance. In that case if we donot > have such a network abstraction service the cache needs to > develop/pick up an existing network protocol and implement > inter cache synchronization process > OR > if the network service is available it can just post the > message to service and donot bother about how the system > delivers the message. > > Am I missing out something that would make the network > service redundant.
Keep in mind that we have not addressed all of the issues yet, or even started down this road. > Also would it make more sense for component to decide how it > wants to manage the data processing i.e. in distributed mode > or local mode OR should container decide that by generating > an appropriate proxy for the component i.e. in a typical > distributed scenario in present day (just a guess based on > what I have seen in my small life) the emphasis seems to be > more on multiple instance of components with ability to talk > to each other rather than different components talking to > each other over network. Also keep in mind that we have ConnectionManager components (Cornerstone) that will allow any component to register a ConnectionHandler object, which will be invoked with every connection made. That ConnectionHandler object takes care of the protocol level issues, and interacts with the component that registered it in the first place. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
