-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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
