commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Essl <christiane...@yahoo.de>
Subject Re: [HiveMind] Basic questions about Service
Date Thu, 25 Sep 2003 07:28:22 GMT
I still mean a - traditional - database provides a good (better) service. 
The reasons for this are the semantic and pragmitical levels of information 
which are very influenced by the way the underlaying data is used. An OO- 
database as I see binds to early the functionality to the data and 
therefore restricts the potential semantic and pragmitcs of the data. In a 
traditional DB the data interrelations are given not until the query. A 
direct result of that is that it is easy to move data from one domain to 
another, to do data-mining etc. As said what is functional and what is a 
good service depends on what the user finds functional. There is no common 
standard like there is no standard in a market-economy (contrary to a 
communistic world) that says this shoe-color is good and that bad.

Apart of this for me Services and Service-Archticture are rather a question 
of software-design philosphy and not so much of programming-technology. As 
I see these design questions are a bit above (or beside) the OO thing. I 
think services can be better compared to concepts like frameworks, (plugins 
in ) plugin-architcture etc than to OO. And all thinks like that can be 
implemented with or without OO.
   On Thu, 25 Sep 2003 00:36:06 -0400, Harish Krishnaswamy 
<hkrishnaswamy@comcast.net> wrote:

> I agree with all your points except the database example. A database, if 
> built respecting OO principles, should bundle its metadata and its 
> funtionality/behavior into classes that provide the service; the user 
> data is aside the point.
>
> -Harish
>
> Christian Essl wrote:
>
>> I think thats realy an intresting question. I mean I don't realy know 
>> but I think - as you do - a Service provides a specific functionality. 
>> However I am not sure wheter this must always be data-hiding - just look 
>> at a database, which provides a good service. I also believe that one of 
>> the first ideas of OO was that you build big systems out of a number of 
>> robust small peaces which have a well defined cloased interface so that 
>> they can evolve independently. That's certainly what services (at least) 
>> in HiveMind are. Another idea I think was that the small pieces can work 
>> together without the need of a central main-component, so that new 
>> combinations can be build flexible. And last I think there is also a 
>> notion of competition on ideas on how to provide a better service to the 
>> user - without centralized normativ control. It is up to the user (and 
>> anyone can be user) what he needs and what service he uses and it is up 
>> to the service to provide well what it promisses - and if it is just 
>> data.
>>
>> On Wed, 24 Sep 2003 21:39:16 -0400, Harish Krishnaswamy 
>> <hkrishnaswamy@comcast.net> wrote:
>>
>>> 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/

Mime
View raw message