commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hls...@comcast.net>
Subject RE: [HiveMind] Basic questions about Service
Date Thu, 25 Sep 2003 17:04:54 GMT
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
> 


Mime
View raw message