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] Basic questions about Service
Date Thu, 25 Sep 2003 17:17:26 GMT
Do you mean remotability? Could you please share some of the things that 
you think are advantages of J2EE over HiveMind?

-Harish

Howard M. Lewis Ship wrote:

>No absolutely ... J2EE provides a lot.  I think HiveMind interceptors could perform transactions
and
>security checks as well, but ultimately, J2EE/EJBs are appropriate for some things.  You
have
>noticed EJBProxyFactory, right? That's the gateway that encapsulates JNDI lookups and
EJB home
>resolution, so that EJBs appear as HiveMind services.
>
>--
>Howard M. Lewis Ship
>Creator, Tapestry: Java Web Components
>http://jakarta.apache.org/tapestry
>http://jakarta.apache.org/commons/sandbox/hivemind/
>http://javatapestry.blogspot.com
>
>  
>
>>-----Original Message-----
>>From: Christian Essl [mailto:christianessl@yahoo.de] 
>>Sent: Thursday, September 25, 2003 11:53 AM
>>To: Jakarta Commons Developers List
>>Subject: Re: [HiveMind] Basic questions about Service
>>
>>
>>Yes I agree with you. I also agree that HiveMind is easier to 
>>use than 
>>EJBs. But I also have to say that until HiveMind supports 
>>transactions, 
>>messaging, security, persistence etc. and that all in a 
>>possible clustered 
>>enviroment there is still quite a way to go. So I do not 
>>currently (and for 
>>the near future) see HiveMind as any form of a replacement of J2EE.
>>
>>I rather see it as something which helps to better structure 
>>and support 
>>your 'normal' applications and provides a facade to EJBs. Ie 
>>in the Web 
>>tier I imagine Services like caches, validators, pools, front 
>>security 
>>checking, access to templates etc. Maybe also connections 
>>pools, hibernate- 
>>services etc. for more simple web-apps.
>>
>>On Thu, 25 Sep 2003 10:17:11 -0400, Howard M. Lewis Ship 
>><hlship@comcast.net> wrote:
>>
>>    
>>
>>>What your are describing is pretty close to J2EE dogma.
>>>
>>>A service facade (stateless session bean) is a business process
>>>concerning Employee.
>>>
>>>An additonal service, behind the facade, provides persistancy for
>>>Employee objects, i.e., its a Data
>>>Access Object (really, a Data Access Service).
>>>
>>>There's nothing inherently wrong with this model, and much that is 
>>>right.
>>>
>>>I've used other systems, including Apple's Enterprise Objects 
>>>Framework,
>>>that merges the Value
>>>object (called an EO, or "Enterprise Object") with its 
>>>      
>>>
>>business logic. 
>>    
>>
>>>This is attractive, but
>>>doesn't scale well ... it works out to be nice to seperate the data 
>>>aspects (the value object and
>>>the data access service) from the business logic, because 
>>>      
>>>
>>business logic 
>>    
>>
>>>is much more likely to
>>>change over time ... or even be quite dynamic (for example, 
>>>      
>>>
>>driven by a 
>>    
>>
>>>flexible workflow engine).
>>>Once you start thinking about externalizing business logic, 
>>>      
>>>
>>it ends up 
>>    
>>
>>>making sense (to me) to
>>>externalize all of it, for consistency.
>>>
>>>Good, workable, scalable OO is more about aggregation than about
>>>inheritance. Coming out of the
>>>Objective-C/Apple/NeXT world initially, my early work on Tapestry 
>>>reflects an overuse of inheritance
>>>over aggregation (even today), a mistake I'm not making 
>>>      
>>>
>>with HiveMind.
>>    
>>
>>>Where HiveMind rocks over J2EE is that it is much, much, 
>>>      
>>>
>>much easier 
>>    
>>
>>>to
>>>create new services and make
>>>them seemlessly work together.
>>>
>>>--
>>>Howard M. Lewis Ship
>>>Creator, Tapestry: Java Web Components 
>>>http://jakarta.apache.org/tapestry
>>>http://jakarta.apache.org/commons/sandbox/hivemind/
>>>http://javatapestry.blogspot.com
>>>
>>>      
>>>
>>>>-----Original Message-----
>>>>From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net] Sent:
>>>>Wednesday, September 24, 2003 9:39 PM
>>>>To: 'Jakarta Commons Developers List'
>>>>Subject: [HiveMind] Basic questions about Service
>>>>
>>>>
>>>>I am a little confused now. I am confused as to what the 
>>>>        
>>>>
>>boundaries 
>>    
>>
>>>>of a
>>>>service are. Is there even a distinction between a Service 
>>>>        
>>>>
>>and a domain 
>>    
>>
>>>>object? I start seeing people actually suck out the 
>>>>        
>>>>
>>behavior of domain 
>>    
>>
>>>>objects into services and have the domain object as a 
>>>>        
>>>>
>>simple JavaBeans 
>>    
>>
>>>>data object. I literally saw an example that had an 
>>>>        
>>>>
>>Employee object 
>>    
>>
>>>>which represented the database table and an EmployeeService which 
>>>>represented the behavior for the Employee object. To me 
>>>>        
>>>>
>>this sounds like 
>>    
>>
>>>>its against the principles of OO (assign the responsibility to the 
>>>>information expert). So this leads to a more basic 
>>>>        
>>>>
>>question - what is a 
>>    
>>
>>>>Service? I think we need a technical definition for 
>>>>        
>>>>
>>Service. I thought 
>>    
>>
>>>>of the Service as an interface to a subsystem / a specific 
>>>>        
>>>>
>>function. Am 
>>    
>>
>>>>I missing something?
>>>>
>>>>-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
>>>
>>>      
>>>
>>
>>-- 
>>Using M2, Opera's revolutionary e-mail client: 
>>http://www.opera.com/m2/
>>
>>
>>---------------------------------------------------------------------
>>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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message