commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harish Krishnaswamy <hkrishnasw...@comcast.net>
Subject Re: [HiveMind] HiveMind ideas
Date Wed, 03 Mar 2004 19:49:48 GMT


Howard M. Lewis Ship wrote:

>This would be valuable discussion for the coming hivemind mailing lists and wiki.
>
>
>  
>
>>Hi Howard,
>>
>>  I've been looking pretty closely at HiveMind for the past 
>>few days --
>>glad the IP issues have been squared away -- and I have to 
>>say, it looks
>>terrific.  I have a couple of minor comments and questions:
>>
>>- The use of integers for ordering makes me squeamish.  Have 
>>you looked
>>at Perl 6 at all?  Larry Wall's insight for operator 
>>precedence ordering
>>might apply here as well.  In Perl 6, you define an operator's
>>precedence relative to another operator (see Apocalypse 6,
>>http://dev.perl.org/perl6/apocalypse/A06.html).  I think this would
>>apply to the things that need ordering in HiveMind too, and would be
>>easier to manage than integers.
>>    
>>
>
>I have thought about putting in before and after attributes to replace order, i.e.
>
>  <interceptor service-id="PerformanceInterceptor" 
>	before="hivemind.LoggingInterceptor"
>	after="SecurityInterceptor,othermodule.FooInterceptor"/>
>
>It's a question of correctness vs. utility. I think a dependency based solution is more
correct, but
>the benefits of implementing and documenting it may not be worth the effort for the rare
case where
>a service has lots of interceptors.
>
>In fact, another option, potentially a better one, was to define groups of interceptors
>(with a particular ordering) to apply to a service, instead of "a la cart".
>  
>
The primary reason for order is because of the distributed nature of the 
contributions. To me, the before/after does not seem to serve any 
special purpose. If you knew all the interceptors for the service point, 
you will very well know their ordering too. As long as we have the 
HiveDoc document the modules in a combined fashion, I am fine.

>
>  
>
>>- Why use Javassist instead of dynamic proxies?  Poking around your
>>blogs a little I see that the transition to Javassist 
>>happened sometime
>>last summer, but I don't see any discussion of why.  Just 
>>performance? 
>>Or are you manufacturing classes in ways that dynamic proxies just
>>wouldn't work for?
>>    
>>
>
>I no longer have a valid comparison. With Javassist, you don't have the object creation
expense of
>creating wrappers around primitive types, or any of the other reflection type overhead.
 In
>addition, given the order of creation (core interceptor, then each interceptor in turn),
the
>interceptors will know the specific class (not the service interface) of the object they
wrap, so
>they can use the more efficient virtual invocations, not interface invocations.  Sort
of buying back
>a little performance. I found it more straight forward to do some other things, such as
properly
>override toString() in a proxy or interceptor (through this can be done using dynamic
proxies, but
>it's less graceful).
>  
>
I am yet to explore Javassist, but would certainly like to see some 
comments comparing it to Cglib2. I have seen some great reviews for it 
and not to mention its widespread use in other products.

>
>  
>
>>- I believe your placeholder for version checking is at the 
>>wrong level.
>> I think versioning should be at the service interface level, not the
>>module level.  Isn't that how Eclipse does it?  What are your 
>>thoughts here?
>>    
>>
>
>I'm pretty sure module level makes sense. Eclipse does it that way.
>
>
>  
>
>>- I remember reading on your blog (I think?) a few days ago that you
>>were thinking of moving the definition of model from the service point
>>to the implementation.  This sounds right to me -- or at least, it
>>should be possible to do this at the implementation level 
>>instead of the
>>interface level, though for some interfaces I guess the 
>>interface itself
>>might need to dictate the model of any implementation.  Any further
>>thoughts on that?
>>    
>>
>
>
>I think it does belong on the implementation, not the <service-point>. I don't think
any interface
>mandates a particular service model. Certainly, with collaboration, the service may appear
stateful,
>but in fact, be stateless ... but be a facade, collaborating with 
>a mix of stateless and stateful services.
>  
>
I agree with Howard, to me, it is certainly an implementation aspect.

>  
>
>>- One of the things we need to be able to do is to choose particular
>>service implementations at startup time, based on property or 
>>preference
>>settings.  In particular, I'd like to be able to swap out all remote
>>services in favor of local (dummy) services based on a single property
>>value; or choose local over remote on a service-by-service basis.  The
>>only way I can think of to do this sort of thing in a general 
>>way would
>>be to have some kind of boolean expression associated with a service
>>implementation that tells HiveMind whether to use that 
>>implementation or
>>to go on to the next available implementation.  (I guess I'm thinking
>>OGNL or something equivalent.)  Any thoughts on how I could accomplish
>>this within the current HiveMind implementation?
>>    
>>
>
>I've thought about this as well. The approach I'm going to explore is
>a "broker" core service implementatation factory. It will be provided with descriptions
>of other services and can dynamically select one.
>
>So, you might have module.PublicService by the service id referenced in your code (or
injected into
>other services).  Its builder will select either module.StandardService or module.DebugService
at
>runtime.
>
>Another option would be to add an attribute to <create-instance> and <invoke-factory>
to allow
>HiveMind to help with the selection, and enabled attribute as you alluded to, might be
a reasonable
>shortcut.
>  
>
I am a little confused here. If it is simply a question of setting up 
test services and production services, why not have two different 
modules with the appropriate services? The hivemodule.properties can 
help there too. But if it is a truly runtime requirement, then will the 
registry.getService() choose an appropriate service everytime its 
called? Meaning you will have multiple implementations for the service?

>
>  
>
>>- I think you should lose the phrase "HiveMind doesn't have any
>>particular purpose" on your front page.  Seems to me it has a very
>>particular purpose, which is to manage services within a JVM.
>>    
>>
>
>Good point.
>
>  
>
>>  Anyway, thanks for this codebase.  It looks very cool!
>>    
>>
>
>I'm looking forward to using HiveMind in virtually everything I do.
>
>--
>Howard M. Lewis Ship
>Independent J2EE / Open-Source Java Consultant
>Creator, Tapestry: Java Web Components 
>http://howardlewisship.com
>  
>
-Harish

>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message