more distributed services

[J Aaron Farr <ja...@yahoo.com>]

Hello.

I'm working on an avalon-based DAO framework over at jingdao.sourceforge.net. 
Only a _very_ basic implementation is in CVS now.  As I've been evaluating my
needs for this DAO Manager I've bumped into a number of ideas are related to
the current discussions about JNDI and bundles (I think).

In the course of managing our model/DAO layer, I've encountered times when some
DAO's need to be remote while others could be local.  One rather nice solution
to this is to have the remote DAO's be hosted by an Enterprise Object Broker
(EOB) server while the local DAO lifecycles are just handled by the DAO Manager
itself.  The location of the DAO can be specificed in the manager configuration
file and in the case of remote DAO's hosted by EOB lookups can be done via
JNDI.  The client application can then access the DAO or model code without
having to worry about whether it's local or remote since this is a deployment
issue.

This got me thinking about the use of JNDI to access Avalon services
(components, blocks, appliances, what have you) in general.  In particular it's
a intereting problem when dealing with multiple containers distributed across
seperate virtual machines.  Instead of a DAO Manager, one could consider the
case where a ServiceManager allows components to lookup services that might or
might not be remote.  The calling component need not know about a service's
location if the container were able to handle remote service lookups (probably
via JNDI).

I'm still trying to understand some of the bundles/distribution units and JNDI
discussion so I'm not certain how related this idea of remote service lookup
is, or what the current direction (if any) is.  If I'm not too far off base,
could someone point me to any work currently being done?  If not, any
suggestions on starting?

Thanks
jaaron

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: more distributed services

[Stephen McConnell <mc...@apache.org>]

J Aaron Farr wrote:

>Hello.
>
>I'm working on an avalon-based DAO framework over at jingdao.sourceforge.net. 
>Only a _very_ basic implementation is in CVS now.  As I've been evaluating my
>needs for this DAO Manager I've bumped into a number of ideas are related to
>the current discussions about JNDI and bundles (I think).
>
>In the course of managing our model/DAO layer, I've encountered times when some
>DAO's need to be remote while others could be local.  One rather nice solution
>to this is to have the remote DAO's be hosted by an Enterprise Object Broker
>(EOB) server while the local DAO lifecycles are just handled by the DAO Manager
>itself.  The location of the DAO can be specificed in the manager configuration
>file and in the case of remote DAO's hosted by EOB lookups can be done via
>JNDI.  The client application can then access the DAO or model code without
>having to worry about whether it's local or remote since this is a deployment
>issue.
>

+1

>
>This got me thinking about the use of JNDI to access Avalon services
>(components, blocks, appliances, what have you) in general.  In particular it's
>a intereting problem when dealing with multiple containers distributed across
>seperate virtual machines.  Instead of a DAO Manager, one could consider the
>case where a ServiceManager allows components to lookup services that might or
>might not be remote.  The calling component need not know about a service's
>location if the container were able to handle remote service lookups (probably
>via JNDI).
>

JNDI isn't really the issue here - as far as a consumer component is 
concerned it get a service - it the container's problem as to how that 
service is established (i.e. the consumer see a service manager).  This 
means that the notion of a client component is reflected in either (a) a 
deployment directive in something like a block.xml file, or (b) 
serialized objects or object reference returned from invocation against 
the local stub of a remote service.  As mention in the earlier email - 
the serialized objects can be fun because you can spin them into 
client-side components on-the-fly.

I do agree that you need a directory service at some point, but that's 
more of a container concern with respect to the resolution of remote 
service references (its not an absolute necessity - but it does help).

>I'm still trying to understand some of the bundles/distribution units and JNDI
>discussion so I'm not certain how related this idea of remote service lookup
>is, or what the current direction (if any) is.  If I'm not too far off base,
>could someone point me to any work currently being done?  
>

Ok - the currently Merlin implementation uses a URL scheme to identify 
services.  Today that scheme is limited to the addressing of services 
within the scope of a single JVM - however, the protocol allows for the 
addressing of external hosts.  What I'm aiming for is the ability to 
preserve the block:// URL protocol but enable mapping of remote service 
addresses as the definition of the service.  For example, the current 
implementation maps something like

  block://xxx/yyy/xxx#MyService

..to a service interface under the partition xxx/yyy/zzz in the current 
JVM.  In the future you will be able to declare a redirection such that 
the address maps to a remote service (i.e. the redirection replaces a 
<component> directive).  I have some code that does this based on Merlin 
2.0 and it will be coming into 2.1 sometime soon.

Cheers, Steve.

p.s. But that's not the complete story - we still need to establish an 
availablity/notification protocol to handle propergation of transient 
decommissioning and redeployment issues.

I..e. lots of fun stuff still to be done!

:-)

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org