On Tuesday 04 November 2003 09:50, Stephen McConnell wrote:
> This is what Merlin can do today (without any extension).
>
> $ merlin http://dpml.net/merlin/tutorial/blocks/hello.block -execute
Spending a few seconds of thought on Jini features in Merlin.
Jini always specifies a Service interface, and this fact can be leveraged to a
great degree.
Client scenario;
The Merlin ServiceManager returns a dynamic proxy of the Service interface,
and will asynchronously register lookup with the Jini Lookup Service (LUS)
for services.
When any of the methods are invoked on the dynamic proxy, it will block
(perhaps with a timeout) until a service is available.
Service scenario;
To provide Jini-agnostic services as Jini services is probably not possible,
as a Service interface must be available, and all methods of the Service
interface must throw RemoteException, otherwise the interface is not RMI
compliant.
This could be done with a a wrapper, but I think it has to be hand coded (BCEL
could do, I guess, but is outside my realm).
Now, assuming that is provided, Merlin needs to create a Service Proxy
(typically, a non-remote object) that references the service itself, which it
(proxy) then registers in the LUS.
I think it is possible to generate a Dynamic Proxy as the service proxy, if
the Avalon Service doesn't provide one.
Now the hard part;
In the current Avalon/Merlin architecture, dependencies are resolved at
start-up, and if dependencies can't be met, the component will not be
deployed. In a Jini environment, this can not be like this. I.e. A dependency
could be fulfilled at a later point in time, and until such time, an
application should ahve a graceful fallback strategy.
For completely Jini agnostic clients, the only fallback I can think of is
"wait-for-a-while-then-fatal-failure", but it would hardly make Merlin a nice
Jini-enabled container.
So what is missing?
I think (without any deeper analysis, as usual), that by allowing cilents to
be JiniAware and services to be JiniCapable, something like this would be
ideal;
public interface MyServiceInterface
{
void doSomething() throws RemoteException, MyException;
}
/** @avalon.component name="myOne" lifestyle="jini"
@avalon.service type="org.hedhman.niclas.MyServiceInterface"
*/
public class MyServiceImplementation extends AbstractLogEnabled
implements MyServiceInterface
{
public void doSomething() { };
}
/** @avalon.dependency type="org.hedhman.niclas.MyServiceInterface"
*/
public class MyClientComponent extends AbstractLogEnabled
implements Serviceable, ServiceListener
{
private MyServiceInterface m_Service;
public void service( ServiceManager man )
{
// Instead of requesting service, we register an interest in
// a service, and the service manager provides it when
// it finds one that is available.
man.requestService( this, MyServiceInterface.getClass().getName() );
}
public void serviceAdded( ServiceEvent event )
{
m_Service = (MyServiceInterface) event.getService();
}
public void serviceRemoved( ServiceEvent event )
{
m_Service = null;
}
}
I'm sure some more detailed thinking is required to iron out the details, but
I think I already can draw the following conclusions;
1. Servicing Jini services to Jini agnostic clients is possible.
2. Registering non-Jini services to Jini LUS is not possible (BCEL excl).
3. Optimal solution introduces asynchronous dependency resolution, I believe
the ServiceListener being the minimal way to provide for that.
Would be fun to work on it, but I am right now going to concentrate on the
tool side.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
