Thank you for your insights, Howard. Much interesting. -----Original Message----- From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] Sent: Monday, November 29, 2004 10:22 PM To: [email protected] Subject: Re: More thoughts & issues about ServiceModels
On Sat, 27 Nov 2004 23:28:01 +0700, Jean-Francois Poilpret <[EMAIL PROTECTED]> wrote: > 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. As you saw, the Module interface gives you access to services and configurations. > > 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). It's an instance of ShutdownCoordinator, but not necessarily the same instance as the service. There are some "bootstrapping" issues in HiveMind: if you make everything perfectly well defined in HiveMind, then you end up with a system that doesn't work ... for example, <create-instance> seems to duplicate hivemind.BuilderFactory ... but without <create-instance>, we couldn't create the BuilderFactory in the first place. > 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="..."/> This might be nice, but as you've seen, you can work around this limitation. Creating new service models is pretty darn rare. > > 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). With the advent of the object translator (late in the 1.0 cycle) I started thinking less about everything is a service, and more about "object soup". People are clamorring for something half-way between a pure bean (instanatiated but not configured) and a full service ... a bean that can be instantiated and configured, but doesn't have a service interface (and therefore can't be intercepted or have a complex life cycle). > > 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). My experiments showed that memory consuption, especially during the calling sequence, was much lower with Javassist proxies than with JDK proxies. The performance, in my test harness, was barely noticable otherwise. I still prefer Javassist, it's more natural to me than JDK proxies. It might be interesteding the carefulyl define the operations accomplished with the different proxies in terms of reusable patterns. I.e., "create a proxy with this interface that delegates to this object" or "invokes this method of this object, then delegates to that" or "injects this method call before delegating" etc. Anyway, come up with a higher level description of what the proxy should do, and have code that creates the proxies using Javassist (if available) or JDK proxies (if not). > > 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? > Many app servers run with much higher numbers of classes and instances per "service". HiveMind does encourage a much finer-grained approach (lots of really tiny services). Fewer instances total because of use of singletons in most cases (vs. object pools for stateless session EJBs). -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind http://howardlewisship.com --------------------------------------------------------------------- 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]
