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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
