shashank d. jha wrote: > Two instances of service is executing now? (may be possibly service is > re-used from service repository (instances are not same as object > instances as mentioned by you) . Still min. two instances of service > must exist to support two different contract). > > Or single service is running, and different clients interact with > service using different contract, as such service is same.?
I think this discussion is really not going down a path of useful result. It is true that all of the attributes of connectivity provide part of the 'contract' of the service. But, variability of connectivity capabilities is also a description of the service. So, in the end, the ability to provide access on separate networks, using separate wire protocols, using separate invocation layers etc. is nothing more than a more flexible service contract implementation. With Jini, we do this quite readily using the JERI stack to change these things at deployment time. Other messaging/invocation technologies have similar capabilities. Unless the services operations are limited/controlled by these details, it really is the same service. A simple example would be encryption. The presence of such a wire protocol facility, application data wrapping detail, might control which functions a service would allow the user to execute. This is still part of the service contract. It is controlled by the invocation environment, but that does not change the fact that it is a capability of the service which is simply controlled/requested by the access/invocation/transport mechanism/interface. Gregg Wonderly
