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 18:50:45 GMT
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
>>
>
>
>


Mime
View raw message