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 14:37:36 GMT
I totally agree with you on separating the data access service out from 
the actual business object, in fact this is exactly what I have done 
previously in one the projects. But I had not separated the business 
logic and data, instead we had a data transfer object which was 
primarily an aggregation of the required data for a particular client. 
But I see your point about scalability, so does the data access service 
now wrap the data object with the business object when asked for an 
entity? That actually really sounds cool, 'cuase conceptually it is 
still one object just physically separated out for scalability and 
maintenance, am I right?

-Harish

Howard M. Lewis Ship 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
>
>
>  
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message