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 19:27:53 GMT
I just wanted to say what JSEE can do. And you are right there is certainly 
the move to use more POJOs or less heavy Services. And your are also right 
that we are the industry, but you know standards are often a bit reluctant 
in recognizing that - and standards are strong.

Another question regarding Bills DAO. Has the service interface a sort of 
close() method, or how do you close the connections? You know I was 
thinking about a shut-down process for HiveMind (comparable to the 
initilizeObject() method). But I am not sure anymore if this is of any use. 
What do you think?
 On Thu, 25 Sep 2003 14:50:45 -0400, Harish Krishnaswamy 
<hkrishnaswamy@comcast.net> wrote:

> Sure the J2EE container has a lot more to offer than what HiveMind does 
> and is an industry standard now. But a lot of people are moving more and 
> more away from the container towards POJO services because the container 
> does not lend itself to agile development (the key to a successful 
> project a lot of people think and I agree). So I guess my initial 
> question should have been - what service in the container really belongs 
> in a container and should not be extracted as a POJO service. It 
> certainly is a lot of work to redo all these services as POJO services 
> but looks like we (the industry) have already started moving in that 
> direction.
>
>
>
> Christian Essl wrote:
>
>> (I have put your mails together)
>>
>>> Well there are some instruments involved but a lot of it is basically 
>>> workflow. I am currently envisioning HiveMind to provide the glue 
>>> between the various services that the lab provides.
>>>
>>
>> Oh I see you mean HiveMind services to wrap current lag-services and 
>> than use other services to glue it togehter. That is a good idea. Maybe 
>> you could tell us more when your prototype evolves.
>>
>>> Do you mean remotability? Could you please share some of the things 
>>> that you think are advantages of J2EE over HiveMind?
>>
>>
>> Remotability is ceratinly an issue (and a good idea). It is needed for 
>> clustering. I think it could be poosible to provide a Service which is a 
>> sort of Hub/Stub creator and provides Remoteability this way. (Of course 
>> the remote enabled services are than not anymore so free in their 
>> interface definition - and there are also other issues).
>>
>> As you know J2EE is a lot of things Servlets, EJBs, JMS, JMX, JTM etc 
>> etc. And EJBs alone (I think that's what we are speaking here about) 
>> EJBs a lot of things: transactions, concurrency control, security, 
>> persistence, legacy connectors and remoteability. (However there is 
>> nothing which prevents HiveMind to do the same - it is only a lot of 
>> work).
>>
>> I think the main advantage of EJBs is just that is an industry standard. 
>> When it comes to things like transactions bosses seem to like industry- 
>> standards - when something goes wrong you and they are just in a better 
>> legal or company internal situation. Industry standards have better 
>> tool-support and better connections to legacy-systems.
>>
>> It is right what Howard says that EJBs are unnecessaraly complicated to 
>> implement and test but they are a standard and fighting standards is 
>> hard (even for Billy G, who basicly says the same about EJBs as Howard).
>>
>> However thanks to God nothing prevents a inovative good small project 
>> like HiveMind to also become an Industry Standard, but not (or extremely 
>> unlikely) in direct confrontation with an existing. I think it has to 
>> find a field and be there realy the thing you need - like HiveMind has 
>> with this free glueing together.
>>
>>> -Harish
>>>
>>> Christian Essl wrote:
>>>
>>>> That is a proof for the diversity of things HiveMind can be used for. 
>>>> Do you think of using services as a sort of connector to different 
>>>> lab-instruments. I also have to say that I do not realy understand a 
>>>> lot (better nothing) of LIMS (Labrartory Information Management 
>>>> Systems)
>>>>
>>>> On Thu, 25 Sep 2003 13:13:46 -0400, Harish Krishnaswamy 
>>>> <hkrishnaswamy@comcast.net> wrote:
>>>>
>>>>> Well, may be not "real" real, we are just going to develop a basic 
>>>>> LIMS system prototype for our lab here. Although some of our 
>>>>> prototypes have taken a life of their own!
>>>>>
>>>>> -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