Good point. It is architecturally unsound to allow for shared, mutable, state. Perhaps controlling access to shared immutable state would be a better requirement.
Let's say I have a data access mediator service with a C.R.U.D. business interface for traditional consumers and a metrics/statistic interface like so: getUpdateCount getReadCount getFailuresCount getMostFrequentlyOccuringSelectStatement All of these methods should, ideally, not pollute the business interface, nor should a traditional user of the business interface be allowed access to the statistics interface. The first step to such access management, in my opinion, is allowing for a separate interface/service that maps onto the same implementation as the business interface/service. After that would be tracking call outs - making sure a service can only invoke services it indicates in its descriptor. Naresh Sikha -----Original Message----- From: Harish Krishnaswamy [mailto:[EMAIL PROTECTED] Sent: Thursday, May 20, 2004 9:27 AM To: [email protected] Subject: Re: Hivemind questions Does your service have any shared mutable state? If not, this is probably not an issue, I suppose, except for duplicate instances each with a different interface. If it does have shared state, then it is a problem, I think. But then again a service is intended to be stateless (or rather with immutable state). I completely agree with your service ID proposal, except there should be an option, for rare cases, to provide multiple implementations of a service. And my suggestion would be to keep the service interface as the primary ID and an additional string identifier in the event it is needed. But it is too late now, I suppose, to change this. -Harish Sikha, Naresh wrote: > I think I mean the first question, "Do you mean, have a single > implementation but have multiple services (and multiple service > interfaces)?" > > In my problem domain it is desirable to have one implementation that > may be tracking statistics or offers methods that can mutate the state > (management extensions), i.e. 'infrastructure interfaces', as well as > offering a business interface. > > For the business interface it is further desirable to add interceptors > such as logging and metrics. > > But for the infrastructure interfaces it is further desirable to have > fewer or no interceptors at all. > > And it should be possible to not cast from one interface to another - > which is guaranteed by Hivemind by virtue of the fact that they are > exposed as multiple services. > > Thanks. > > Regarding my second question on the use of serviceIds a good example > of not (at least technically:) needing a serviceId is the lookup to > the ThreadEventNotifier. Since there really only is one in a system, then > > getService(ThreadEventNotifier.class) > > is as descriptive as > > getService(Hivemind.THREAD_EVENT_NOTIFIER_SERVICE, > ThreadEventNotifier.class); > > Thanks again. > > > *Naresh** Sikha* > > -----Original Message----- > *From:* Howard M. Lewis Ship [mailto:[EMAIL PROTECTED] > *Sent:* Thursday, May 20, 2004 8:55 AM > *To:* [email protected] > *Subject:* RE: Hivemind questions > > Do you mean, have a single implementation but have multiple services > (and multiple service interfaces)? > > Or do you mean, have a single implementation and single service, but > allow it to implement many interfaces? > > > > > -- > Howard M. Lewis Ship > Independent J2EE / Open-Source Java Consultant > Creator, Jakarta Tapestry > Creator, Jakarta HiveMind > http://howardlewisship.com <http://howardlewisship.com/> > > -----Original Message----- > *From:* Sikha, Naresh [mailto:[EMAIL PROTECTED] > *Sent:* Thursday, May 20, 2004 10:52 AM > *To:* '[email protected]' > *Subject:* Hivemind questions > > Hivemind users, > > I have the following questions I'm hoping you can help me with. > > 1. Is it possible for a service to expose multiple, distinct, > interfaces? An example is a service that exposes a 'business > interface' (getQuote) and an 'infrastructure' interface > (getQuoteHitCount). Using multiple interfaces allows for exposing > only the necessary methods to the appropriate consumers while > still preserving the singleton semantic. > > 2. What is the goal of making 'serviceId' distinct from > 'serviceInterface'? For brokering pattern situations (many unique > instances of a common interface like Servlet) I see value here, > but for true singleton services it would be convenient to only > have a dependency on the the interface like so: > > getService(BusinessService.class); > > I guess as much as this is second question is a feature request, I > would like to solicit rationale first for the current design. > > Thanks! > > > *Naresh Sikha* > Senior Staff, Technology Solutions > Charles Schwab & Co., Inc.* * > 211 Main Street > SF211MN-07-347 > San Francisco, CA 94105-1918 > W: 415-667-1286 > F: 415-667-9397 > E: [EMAIL PROTECTED] > *WARNING*: All email sent to this address will be received by the > Charles Schwab & Co., Inc. corporate email system and is subject > to archival and review by someone other than the recipient. > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
