commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <>
Subject RE: [HiveMind] Basic questions about Service
Date Thu, 25 Sep 2003 14:17:11 GMT
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,
doesn't scale well ... it works out to be nice to seperate the data aspects (the value object
the data access service) from the business logic, because business logic is much more likely
change over time ... or even be quite dynamic (for example, driven by a flexible workflow
Once you start thinking about externalizing business logic, it ends up making sense (to me)
externalize all of it, for consistency.

Good, workable, scalable OO is more about aggregation than about inheritance. Coming out of
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

> -----Original Message-----
> From: Harish Krishnaswamy [] 
> 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:
> For additional commands, e-mail:

View raw message