On Saturday 17 January 2004 14:05, J Aaron Farr wrote: > Yep. But the important thing is to maintain separation of concerns. > Lifecycles are separate from Service Dependency. Service Discovery and > Availability are probably close enough to be solved in a single > framework, but Service Dependency is probably a separate issue from > these. Meta data (or Service Description) is a seperate issue too.
Are we looking at these; * Service Discovery * Service Availability and Lookup * Service Description * Service Dependency Resolution * Service Life Cycle * Service Environment (Context) I would like to view these from the perspective of Jini for a second. Service Discovery and Join ==================== Service Discovery a Service needs to announce its presence. They do that via multicase IP communication. Then the Service will Join the Federation. That means that it registers itself with one or many Lookup Services that it finds during the Discovery phase. Service Availability and Lookup ======================= Availability and Lookup is a "client-perspective" operation. You need a service, you can either look it up straight away (just like with ServiceManager in Avalon) or create what they call a LookupCache. That means that the Lookup Service, will notify when a service fulfilling the lookup template (a kind of filter) joins. Through the LookupCache, the rest of the application can register itself as listeners to know when things comes and goes. Service Description ============== Jini has generic attributes for the services. Not only can they "tell story" about the service, such as name, type, location, serial number, expiration date, and so on, but also they are searchable. So when I do the lookup, either direct or via the LookupCache, I can specify that only services that has a particular attribute set to some value will be returned/notified. Service Dependency =============== Jini doesn't have this notion at all. Why not? Typically, the deployer will receive some form of feedback that "Service Abc" is not running and looking closer, it will show that it is because the "Service Def" is not present on the network. Then he/she starts "Service Def" and things continues. Service Life Cycle ============= Jini services has an vague life cycle, not really well articulated, but it seems that it is not needed, probably because the nature of "things comes and goes" very much at any point. * Service construction. * When a Lookup Service is found, register yourself there. * When a Service available notification is received, enable the parts in the application that depends on it. * When a Service not-available notifcation is received, disable those parts. * If a service call fail, disable those parts, and make a new lookup in the Lookup Service. and so on... Service Environment =============== Again Jini doesn't provide any environment or context other than what is provided by other services, such as Lookup Service or the JavaSpaces Service. What can we learn? 1. There are many ways to handle the same thing, and the Avalon way is far from the only, nor the "right" way to do it. 2. None of the listed sub-systems are probably a "requirement", i.e. should be a choice, even Dependency which at first looks very much needed. 3. Components would need to be able to declare which system *contracts* are required in the container to operate properly. 4. Should Context really be a "native" concept? (I can make an argument why not separately if interest exists). I hope you enjoyed this elaboration. Cheers Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
