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:06:25 GMT
Yes, and again, the concept of HiveMind was to extract out the better ideas in Tapestry 3.0
(related
to configuration and services), then use that as the infrastructure for Tapestry 3.1.

--
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 12:38 PM
> To: Jakarta Commons Developers List
> Subject: Re: [HiveMind] Basic questions about Service
> 
> 
> Oh yes that's a good point - now I know even better why I 
> like HiveMind :-) 
> - and I totally agree. Seriously I think this should get 
> somehow on the 
> front-page of HiveMind. You expressed well this free glue aproach.
> 
> What I wanted to say is that for now functionality is missing 
> which could 
> make it a real competitor to J2EE. I did not want to say that 
> HiveMind is 
> worse than J2EE. Howard did and does a realy good job, but 
> nobody can make 
> everything in one day (especially if I come up with a new 
> 'big' suggestion 
> every day).
> 
> HiveMind maybe soon there where EJBs are but to get started 
> used now and in 
> the next week a field where HiveMind can compete with every other 
> technology easaly is the web-tier layer. And I think getting 
> started used 
> is the most important thing for further development.
> 
> On Thu, 25 Sep 2003 12:02:57 -0400, Harish Krishnaswamy 
> <hkrishnaswamy@comcast.net> wrote:
> 
> > The thing I like about HiveMind is the free form schema, that is 
> > awesome.
> > I think that's what allows HiveMind to be really clean and 
> small at the 
> > core and yet allows unlimited possibilities unlike other 
> frameworks where 
> > if you want a new feature you end up modifying the core. 
> HiveMind does 
> > ROCK!
> >
> > -Harish
> >
> > Christian Essl wrote:
> >
> >> 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
> >>>
> >>
> >>
> >>
> >
> >
> > 
> ---------------------------------------------------------------------
> > 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