> -----Original Message----- > From: Peter Donald [mailto:[EMAIL PROTECTED] > Sent: 06 October 2001 06:13 > To: [EMAIL PROTECTED] > Cc: Avalon Development > Subject: Re: [java_services_framework] Action on the list... > > > On Wed, 3 Oct 2001 02:24, Berin Loritsch wrote: > > In many ways, a Service is a very abstract notion. > According to Webster's > > dictionary it means this: > > > > "1) Work or duties performed for others. 2)A facility > offering repair or > > maintenance. 3) A facility providing the public with a utility". > > --Webster's II New Riverside Dictionary > > > > I think that Webster did a good job identifying it for our purposes. > > I like this definition. A service is functionality provided > to a client > through a clearly defined interface. In the java case the > service coresponds > to a java interface and it's associated contracts/javadocs etc.
But then every class could be defined as a service. Isn't there a need to make a clear seperation between what is a standard class style facility and higher level facilities which are implementations of meta-models and business processes rather than micro level issues. > > The object providing this functionality is separate from the service > interface. In Avalon/Phoenix we call this a Block but another > possible term > is ServiceProvider. > > Each ServiceProvider provides 0 or more Services. The > ServiceProvider (SP) > also implements the necessary lifecycle methods to interact with the > Container (or ServiceKernel). So every method that the SP > object implements > can be classified as a lifecycle method, a method that > implements Service or > a utility method used by the other methods. > > The lifecycle methods are used by Container/Kernel to create > and manage the > component. > > SP objects should only be able to interact with other SP > objects via the > Service interfaces. One SP should never be able to call a > lifecycle or > utility method of another SP object. > > SP objects may depend on Services provided by other SP > objects. ie a SP is a > client of a Service provided by another SP object. Service > methods are > only guarenteed to be valid after the SP object is > initialized. Thus the > providing SP object must be initialized before the Client SP. > This means a > dependency (directed acyclic) graph must be built and > traversed (and no > circular dependencies are allowed). > > So I guess I see three separate parts of a Services > framework. Service > interfaces, Service Providers and Container that hosts > Service Providers. > Now the rest of this I'm in agreement with. The only issue is the Provider v the actual Service. I'd see the provider as a service in itself which provides a Facade onto several implementations, but that could just be sematic differences. The model of the stuff we've developed in house here is Client (Proxy) -> Discovery -> Container -> Service Where the service could then go through the same loop to connect to another service. The Client and the Service are concrete, the Discovery and Container is enviroment specific (and therefore driven from config). Steve Jones --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
