And of course all EJB, JMX and WS interfaces, descriptors, implementations, etc will be completely generated in build time... we plan to have a central configuration where we say:
Publish Component A through EJB and WS
Publish Component B as MBean
...and so on
The implementation of this wrappers would just lookup the component on the Registry and delegate all method calling to them.
What do you think?
El lun, 24-05-2004 a las 18:59, Pablo Lalloni escribió:
El lun, 24-05-2004 a las 18:29, Sikha, Naresh escribió:Is the requirement:
1. Be able to use JNDI to find a Hivemind service in a single JVM?
This is what we're trying to implement...
Let me explain a little what we're trying to implement.
1. Business logic on components integrated by HiveMind ("server side")
2. Web app based on Tapestry ("client side")
We envision 2 HiveMind registries: one on "server side" (1) and one on "client side" (2).
Components built and exposed by (1) are wrapped with EJB (SLSB) which manage to lookup them in the (SS) Registry.
(2) is responsable (through an EJBLocalProxyFactory) of looking up those SLSB-EJB in JNDI and expose them as components to the Tapestry webapp which in turn looks them up using HiveMind registry (CS).
Now for this EJBs to wrap business components we need some place to put the SS Registry where they all can access it... so we pretended to create the registry with an MBean and bind it on JNDI where EJBs could get it.
This would be something like:
BusinessComponent ------------ "SS" Registry <--use--- WrapperEJB <---looks up---- "CS" Registry <---use---- WebApp
The WebApp use the CS Registry to get the EJBs which implements the same business interface as the business components registered in SS Registry. This would allow us to switch easily between using or not the EJB layer by just changing the registry where the webapp lookup business components.
We're using Tapestry 3.0 for the web app... there we face the problem of not having an elegant manner to inject EJB components on Tap components because we can't specify a factory for helper beans or application extensions.
Off course we could omit the EJB layer but that is a requirement given the scalability constraints we have on the application and considering the alpha state of HiveMind. Actually the "switching" ability was intended just for being able to stress test how HiveMind behaves under high load.
And yes, all of this is going to run on a single JVM...
Now, I know all this sounds awkward... but... any other ideas?
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.
What would be such a custom protocol?
I'd be happy to contribute an implementation to (1).
Glad to read this
Cheers.
Naresh Sikha
-----Original Message-----
From: Howard M. Lewis Ship [mailto:[EMAIL PROTECTED]
Sent: Monday, May 24, 2004 11:37 AM
To: [email protected]
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: [email protected]
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
<<attachment: smiley-3.png>>
