I think the question is ... how to represent something that is logically all of one piece as several different, collaborating services?
If the different pieces can communicate using events, then you can have an event hub that each implementation registers with. Another alternative is to have a kind of Registrar service that each other service can register with (registering the service implemtentation) so that the differernt implementations can find each other. Can you more specifically address your use case? So far, this is falling under YAGNI for me. -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind http://howardlewisship.com > -----Original Message----- > From: Sikha, Naresh [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 20, 2004 12:45 PM > To: '[email protected]' > Subject: RE: Hivemind questions > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
