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]



Reply via email to