Oops! I reply to my own issue! After digging into HiveMind ThreadServiceModel class, I saw that the Module could be used to get access to a Service or a Configuration. So this should solve the issue I raised yesterday. That is strange: until now I had never got conscious of what Module can do!
Cheers -----Original Message----- From: Jean-Francois Poilpret [mailto:[EMAIL PROTECTED] Sent: Saturday, November 27, 2004 11:28 PM To: [email protected] Subject: More thoughts & issues about ServiceModels Hi all, 1. Issue: I just started working on the "user" service model described in my previous mail, and I encountered some (small) issue: My UserServiceModel class needs access to some external service. Since each instance is constructed by my UserServiceModelFactory, my idea was to inject that external service to the factory, and then pass it as an argument to the constructor of UserServiceModel. However, in HiveMind the ServiceModelFactory is not really a "service". It is constructed directly by its default constructor and there is no possibility (as far as I could see) to inject anything to it. Of course, I have the option, in the UserServiceModelFactory, to get the Registry and then get the service I need from it. But this is not very "clean". Is there any other way? I had a look at the existing ServiceModels implementations in HiveMind, and they all seem "self-contained" (ie, they do not require access to any external service, EXCEPT the ShutdownCoordinator, but this one is directly available from the ConstructableServicePoint passed to the factory). If no other way exists, can this be a suitable evolution for HM1.1? Regarding configuration, it would give something like: <service-model name="..." service-id="..."/> Instead of (or in addition to): <service-model name="..." class="..."/> I think this would be great so that we could say that "absolutely everything" in HM is a service! Currently we can say: "Almost everything" (which is not bad at all, by the way). 2. Wondering about proxies performance: In HM we deal potentially with a big number of proxy classes. In HM, they are all coded with Javassist, but we always have other options for other developments, in particular the -much simpler- dynamic proxy from the JDK. I suppose that Javassist proxies are much faster than JDK dynamic proxies, but my wonder is if this can be significant? Are there comparisons figures between both techniques? And beyond the ratios that can exist, is this really relevant (I mean if there is a 10:1 ratio, but we are talking about 10:1ns, I would not consider it relevant for the applications that I write). I was also wondering about scalability issues related to proxies: as I said before, in HM we deal with a big number of proxies (instances AND different proxy classes); in a real-world application, having so many proxy classes all over the place can be a problem or not? For instance, if we take the following example: - mid-size system with ~100 services (no primitive model) - about 3 interceptors per service on average (eg: log, transaction, authorization) Each interceptor means 1 proxy class for each service Each service has also 1 proxy class (generated by the ServiceModel) So we end up with 400 Proxy classes in this system. If we have only singleton services, this gives 1 instance for each Proxy, so 400 proxy instances. (if we were using threaded or pooled, then each actual service instance needs specific instances of interceptor proxies I think). Here I take the hypothesis that most services are singleton, because in threaded and pooled models the interceptor proxies. Do we have systems that are used and run in such situations? Have there been studies about the impact on memory consumption? That will be all for today! Cheers Jean-Francois --------------------------------------------------------------------- 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]
