RE: Registry

[Sikha, Naresh]

Title: Message

"JNDI is pain" is a statement I heartily agree with. I think the proposal on the table is:

 

- Use a commonly found abstract factory pattern (JNDI SPI) to locate Hivemind services. This is distinct from 'register Hivemind services in JNDI namespace, java:comp/env'. I agree that the latter is 'pain'. The SPI implementation could look like:

 

Context c = new InitialContext();

MyService s = (MyService) c.lookup("service:" + MyService.class.getName()); // custom protocol calls into Hivemind directly w/o requiring a running naming service

 

- Validate the, IMHO good, architecture of Hivemind by providing an alternate means to finding a Hivemind service. This can be restated many ways:

 

    - Use JNDI, itself, as the implementation of the ServiceLocator design pattern.

    - Allow for code that doesn't see the servlet request to get at Hivemind services (and share thread state, etc.).

    - Allow for clients of Hivemind services to not be dependent on Hivemind, itself. This can be restated as, if a service doesn't have the compiletime requirement of being dependent on Hivemind, then, in my opinion the client should also have such freedom of choice.

 

I'm making this proposal based on experience - customers always want their way of interacting with your service (and they'll probably even wrap that as well). Providing multiple outs just validates your architecture of services.

 

Thanks. I'll more than understand if this is not a generally accepted view.

 

 

Naresh Sikha 

-----Original Message-----
From: Howard M. Lewis Ship [mailto:[EMAIL PROTECTED]
Sent: Monday, May 24, 2004 2:36 PM
To: hivemind-user@jakarta.apache.org
Subject: RE: Registry

So, we start with the idea that "JNDI is pain" and now we're trying to make HiveMind look like JNDI?  Well, have fun!

 

 

--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com

-----Original Message-----
From: Sikha, Naresh [mailto:[EMAIL PROTECTED]
Sent: Monday, May 24, 2004 5:30 PM
To: 'hivemind-user@jakarta.apache.org'
Subject: RE: Registry

Is the requirement:

 

1. Be able to use JNDI to find a Hivemind service in a single JVM?

 

or

 

2. Be able to find the same reference to a Hivemind service across multiple JVMs?

 

I agree with Howard's take on (2). (1) is a bit more interesting. It is possible to define a custom JNDI protocol that could facade the most frequently occuring Hivemind service lookup, RegistryBuilder.constructDefaultRegistry().

 

By using a custom protocol you don't need to be serializable.

 

I'd be happy to contribute an implementation to (1).

 

Cheers.

Naresh Sikha 

-----Original Message-----
From: Howard M. Lewis Ship [mailto:[EMAIL PROTECTED]
Sent: Monday, May 24, 2004 11:37 AM
To: hivemind-user@jakarta.apache.org
Subject: RE: Registry

Binding it into JNDI seems to go counter to the expressly single JVM nature of HiveMind. For sharing within an EAR, it works fine as a servlet context attribute.  Sharing between servers in a cluster is the wrong approach ... instead, each server should have its own parallel Registry instance.

 

What with all the dynamic class creation and so forth, the Registry and the services, proxies, interceptors and so forth are bad candidate for serialization. It takes only a fraction of a second to construct the Registry.  If you need to communicate between servers, use JMS.

 

 

--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com

-----Original Message-----
From: Pablo Lalloni [mailto:[EMAIL PROTECTED]
Sent: Monday, May 24, 2004 11:12 AM
To: hivemind-user@jakarta.apache.org
Subject: Registry

Howard,

We're trying to bind a Registry on JNDI but as it's not Serializable we can't...

Any chances of make Registry extend Serializable?

Is this possible?
Or there's any reason for it to not be?

Cheers,
Pablo