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 16:51:14 GMT
Absolutely, I agree it is not yet prime time to go against J2EE (guess 
that's why we have the EJBProxyFactory!) and it very well could, down 
the road. We are actually starting a new small project this coming 
Monday and I may be using HiveMind to try it out for real! It is exciting!

-Harish

Christian Essl wrote:

> 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
>>
>
>
>


Mime
View raw message