Re: Jini Spec API changes - Design Decision - Important

[Peter Firmstone <ji...@zeus.net.au>]

You might be wondering why my recent changes weren't implemented 
earlier, put simply, vision of hindsight is 20:20.

After reading about the reasons why certain decisions have been over the 
evolution of Jini and now River, I can say that River's API is simply 
brilliant, it was put together by some very bright minds, this doesn't 
mean that it's perfect (anything perfect is obsolete), it does have its 
warts, but it's the closest thing to the future of computing I'm aware of.

On the subject of Design decisions, here's a big one I'd like to propose:

    * Depreciate the Lease Service and include the Jini Surrogate
      Architecture with River.

Why?

Well a Lease Service renews a Lease for another Service, however if that 
service fails, the remote Lease Service continues renewing its leases.  
I don't think anything is so reliable that we can guarantee it will not 
fail, therefore the Lease Service contributes to unreliability as it 
violates the Lease contract, that is: when something fails, a lease is 
not renewed and the resources are reclaimed.  Instead a Surrogate could 
maintain a lease for a non java architecture service, when the service 
goes away, so can the Lease.

This discussion excludes the LeaseRenewalManager, which doesn't violate 
the Lease contract, as it renews Leases for remote resources on behalf 
of local applications, simplifying programming.

Best Regards,

Peter.

Re: Jini Activation Framework - A sub project -edited?

[Peter Firmstone <ji...@zeus.net.au>]

Hi Gregg,

Just thought I'd re-edit this, I wasn't very clear:

I'm thinking about how to structure the next distribution release.
Namely, creating a platform release artifact that excludes
Activation and Some Services and creating an Activation Framework release.

Reasoning:
	* Activation's original design intent was preserving
	  valuable resources for multiple occasionally used
	  services running on one server, when server
  	  memory was limited to 512MB and
           the average desktop had 32 - 64MB. Today with
	  server memory of 32GB and clients with 4GB,
	  Activation adds complexity, but the benefits
	  are no longer clear.
	* There is an obvious need to
	  preserve backward compatibility for existing
	  applications that utilise Activation.
	* Activation is heavily tied to Java SE RMI,
	  which appears no longer available on Java CDC platforms.
	* Minimise code differences for Java platform support,
	  to minimise maintenance, support and provide maximum
           commonality of Jini API between different Java
	  platforms.

I had figured a Mahalo implementation should be included in the Apache
Release (without Activation), I want to remove the dependency on
Activation being present in the Classpath.  I'll have to do this for a
Java CDC release anyway.

Your use of Norm is interesting, I didn't want to include Norm in the
base release.  It sounds like your using Norm to control the liveliness
of your exports, it also sound like these proxy's aren't registered with
the lookup service, tell me more?

My thoughts were:

    * A separate release artifact for the Activation Framework.
    * Platform release artifacts for Java SE and Java CDC.

Your comments are making me think:

    * A separate release artifact for the Activation Framework (phoenix,
      specific to Java SE).
    * Basic platform release artifacts (With very wide platform support, 	
      a Java SE 5+ artifact, a separate one for Java CDC 1.11+).
    * Service release artifacts, I want Reggie to take
      advantage of the latest java language and concurrency features.
      But I want to be able to install other services without
      requiring the Activation Framework release to also be installed,
      eg a Transaction Service. I'm still figuring this bit out.
    * Services can be JVM implementation specific, the client doesn't
      need to worry about what happens on the server.  It would be
      desirable though for all proxy's to enjoy wide platform support.
    * Any Proxy's that cannot be supported on earlier platforms won't
      unmarshall and will be returned null in ServiceItem's from lookup
      on those platforms.

Cheers,

Peter.

Gregg Wonderly wrote:
> I use norm and mahalo all the time without activation.  I use a leased smart proxy instead of DGC so that all of the details of proxy management are under my control and I use transactions without activation for mahalos lifecycle.
>
> Gregg wonderly
>
> Sent from my iPad
>
> On May 2, 2010, at 8:37 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
>
>   
>> My reasoning for removal from the platform spec or making it optional: Activation is a Service implementation detail.
>>
>> If there are no objections, I'd like to move it in the near future.
>>
>> Regards,
>>
>> Peter.
>>
>> Peter Firmstone wrote:
>>     
>>> Can we move the Activation Framework to a subproject of Apache River?  So it isn't part of the platform?
>>>
>>> The Activation Framework could be optional and include the following:
>>>
>>>   * Phoenix - Activation Service
>>>   * Norm - Lease Service (This doesn't make much sense outside Activation)
>>>   * Activatable Fiddler - Lookup Discovery Service
>>>   * Activatable Reggie - Service Registrar
>>>   * Activatable Javaspaces - Outrigger FrontEndSpace.
>>>   * Mahalo - Transaction Service (We can create a Non-Activatable
>>>     implementation for the platform)
>>>   * Mecury - Event mailbox (We can create a Non-Activatable
>>>     implementation for the platform)
>>>
>>> These could be bundled together as an Activation Framework Release
>>>
>>> Existing interfaces that are specific to Activation in the net.jini namespace (exclusive of net.jini.activation) could be depreciated and copied to another package namespace, giving existing applications time to transition.
>>>
>>> Then the activation framework becomes something that runs on top of Jini / Apache River, rather than part of it, making Jini / River conceptually simpler to new application developers.
>>>
>>> What are your thoughts?
>>>
>>> Regards,
>>>
>>> Peter.
>>>
>>>
>>>
>>>
>>>       
>
>   

Minimise Codebase downloads Was: Re: StreamServiceRegistrar

[Peter Firmstone <ji...@zeus.net.au>]

Hmm, Gregg, I'm guessing you've got something in mind?  If you do, 
please donate it ;)

My general Ramblings, WARNING: may veer wildly off course, thoughts 
subject to change based on good suggestions too:

Yes, I'm thinking about a URL structure to annotate marshalled data with 
the package name and version number. This should assist people utilising 
OSGi to control ClassLoader visibility using jar Manifests and your new 
CodebaseAccessClassLoader, without River requiring it (what a mouth 
full). OSGi doesn't specify how to deal with deserializing objects, I 
suspect that's why R-OSGi (A Separate entity than OSGi which is a spec) 
has it's own binary serialization mechanism, which is proprietary, it 
doesn't preclude the use of another protocol though.

R-OSGi clearly, is heavily influenced by Jini, however OSGi and it's 
lookup semantics are best suited to their original design focus, JVM 
local modularity.  The OSGi lookup semantics, when applied to 
distributed computing cause problems during deserialization, R-OSGi 
despite having it's own binary serialization, exposes issues with 
ClassLoaders and class visibility because the registrar doesn't declare 
all associated classes (superclasses, parameters, method returns), only 
one interface by name, whereas Jini lookup semantics don't prevent 
determination of these classes allowing for better control of class 
visibility (although this hasn't been done yet other than Preferred 
Classes).  For that reason OSGi Service lookup semantics don't map well 
to distributed systems, but it does do a superb job of providing local 
jvm services, but were concerned with distributed services and they're 
very different beasties.

Perhaps it is fair to say that both Jini and OSGi registrars target 
their intended scope appropriately.  Therefore in an OSGi framework, 
where an application can utilise both Jini and OSGi services, should not 
attempt to map a local OSGi service to a Jini distributed service and 
vice versa, but instead use each for it's intended purpose.

Which brings me back to Service Interfaces, and a past river-dev 
discussion about Maven dependencies, I haven't used Maven, so can't 
comment too much, but you rightly pointed out that the dependencies are 
not on the *-dl.jar but instead the Service Interfaces defined in the 
Jini spec and hence the jsk-platform.jar. This I think, underpins most 
of the misunderstanding surrounding Jini technology, it is the Service 
Interface on which everything depends.  I've thought about this and 
believe that for non platform services, the Service Interface and any 
return or parameter interfaces / classes, should be packaged  (in a jar 
or jar's) separately from service implementations, as indeed, Jini 
service implementations are.  The service implementations (service and 
service-dl jar's) then should depend on the ServiceInterface.jar (SI.jar)

This is where Package Versioning comes in, when you vary your service 
implementation, you want a specific version linking your service.jar to 
your service-dl.jar, well you could just rename both jar's I suppose, 
but that doesn't fit well with some frameworks.  The service 
implementation (service.jar and service-dl.jar) is entirely a private 
concern, no classes that form any part of any public API belong within 
it, you can do whatever you like with any interfaces contained within an 
implementation without harming any external software, so long as the 
service.jar (server) and service-dl.jar (client) versions match.

Everything within a Service Interface jar (SI.jar) should be public API 
interfaces (whether from another jar, java or jini platform API 
classes), it must also be stateless and not require any form of 
persistence whatsoever.

Then ClassLoader visibility should be:

SI.jar ClassLoaders should be made visible to everything utilising it, 
as it forms contracts of compatibility between different Service 
implementations and clients, just like platform API or classes.  When we 
want to extend a Service Interface, perhaps by adding a new interface 
and method, we can increment its version, the version scheme publishes 
the expected level of backward compatibility, that way existing Services 
still work with the new version and the latest and greatest versions 
utilising new interfaces within the SI.jar don't break by loading an 
earlier version and get looked up by both new and old clients.

As an example if we had a Sales Broker Service we might have:

SalesBrokerService.jar - The service interface API.

BobTheBroker.jar - Bob's service implementation.
BobTheBroker-dl.jar - Bob's proxy.

This doesn't prevent Bill also providing the same service:
BillsBrokerage.jar - Bill's service implementation
BillsBrokerage-dl.jar - Bill's proxy.

All implementers use the same SalesBrokerService.jar, the clients do 
too.  The proxy's ClassLoaders are not directly visible to the Client 
Application ClassLoader, instead the client holds a reference to the 
proxy via the SalesBrokerService Classloader class type's, which are 
visible to both the Proxy ClassLoader and Client Application ClassLoader.

This brings me to Codebase downloads and proxy sharing, Bill and Bob, 
don't share proxy implementations, however Bill might provide a number 
of fail over services and want all his clients to use the same codebase.

Common codebase schemes could be broken up in a couple of different ways:

One way to share codebase is utilise the same codebase in different 
ClassLoaders, Bill might want to do this if he uses static class 
variables, specific to each service server node in his proxies (in this 
case Bill's the Principal):
CodebaseA->ClassLoader1->proxy1
CodebaseA->ClassLoader2->proxy2
CodebaseA->ClassLoader3->proxy3

However Bob (The Principal), might be happy to have all of his proxy 
object instances share the same ClassLoader and the same permissions.
CodebaseA->ClassLoader1->proxy1
CodebaseA->ClassLoader1->proxy2
CodebaseA->ClassLoader1->proxy3

The above apply only to smart proxy's.

For dumb proxy's all proxy's must be loaded in the ServiceInterface 
ClassLoader as they are just Java Reflective proxy's and don't require 
additional classes.

Dumb proxy's can be loaded like this:

CodebaseSI->ClassLoaderSI->proxy1- Bob's Service proxy
CodebaseSI->ClassLoaderSI->proxy2 - Bill's Service proxy etc.
CodebaseSI->ClassLoaderSI->proxy3
CodebaseSI->ClassLoaderSI->proxy4
CodebaseSI->ClassLoaderSI->proxy5

And can belong to anyone.

I have exactly no idea at this stage how to communicate these models 
into their respective semantics for determining class loading schemes 
during unmarshalling.

Anyone with ideas don't be afraid to post.

Now something handy that OSGi does is each bundle contains a list of 
permissions it requires, if we adopt this format for permissions for 
Service-dl.jar implementations and perhaps SI.jar too, it enables us to 
specifically restrict permission grants, it is like a contract of trust, 
the proxy tells you prior to loading it how much trust you must bestow 
upon it for full functionality, you might decide to have a set of grants 
tighter than those requested, but that's up to you, the client.

But one thing is clear, we can't afford to download a particular jar 
more than once.

Any new implementations must also play well within an existing Jini 
cluster too, so a Service might register two identical proxy's with 
different  ServiceRegistrar's, one with the old httpmd: URL scheme, and 
one with a new Package Version URL scheme that requires a codebase to be 
looked up.  The actual Service-dl.jar will be the same, just downloaded 
in different ways and loaded in different classloader trees by different 
client nodes.

The interesting part of Jini lookup ServiceTemplate's is it's basically 
looking for instanceof SomeServiceInterface.  The Marshalled proxy needs 
to commmunicate all packages and versions required for unmarshalling at 
the client, this could include any number of jar files to be downloaded.

So it's really all about how we package our services.

Then we can create an upload site with public ServiceInterface source 
and jar files that many people and companies can sign, forming webs of 
trust.  We also need a pool of common Entry classes that people can 
utilise.  That way if we're using delayed proxy unmarshalling, entries 
can be unmarshalled for filtering operations without downloading any 
proxy codebases.

Now we can have an OSGi compatible versioning scheme and simplified 
class loader framework without requiring OSGi (no OSGi Services, no OSGi 
bundle stop / start / persistence), perhaps even utilising some felix 
code in River for people that want versioning but not OSGi, but we 
should also provide the pieces for applications to fully utilise OSGi 
frameworks if they wish too, without requiring other nodes to do so.

Cheers,

Peter.


Gregg Wonderly wrote:
> One of the the things that I played around with was a Protocol handler which would use a URL structure that specified such versioning information.  It would lookup services implementing CodeBaseAccess and ask them if the could provide such a jar file.
>
> This kind of thing makes it easier to deal with some issues about total number of codebase sources, but I am still not sure that it solves the problem you are thinking about.
>
> Gregg Wonderly
>
> Sent from my iPad
>
> On May 5, 2010, at 9:00 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
>
>   
>> The other thing I'm working on is a PackageVersion annotation, using the implementation version and package name from the Java Package Version spec, so developers can version their proxy's allowing sharing of compatible bytecode for reduced codebase downloads.
>>
>> I'm hoping that these things combined will assist to enable lookup over the internet.
>>
>> Peter Firmstone wrote:
>>     
>>> Gregg Wonderly wrote:
>>>       
>>>> Many of my service APIs have streaming sockets needed for I/O based activities.  For example, remote event monitoring happens through an ObjectInputStream that is proxied through the smart proxy on the client to a socket end point that the proxy construction provided the details of on the server.
>>>>         
>>> This too is interesting Gregg,  I've done something similar with the StreamServiceRegistrar; I've created a new interface called ResultStream, to mimic an ObjectInputStream, which is returned from lookup.  The idea is to provide a simple interface and minimise network requests by allowing a smart proxy implementation to request and cache larger chunks.  The main advantage of the Stream like behaviour, is to enable incremental filtering stages and delay unmarshalling of proxy's until after initial Entry filtering, then to control the progress of unmarshalling, so your only dealing with one proxy at at time. Further filtering can be performed after each unmarshalling, such as checking method constraints.  Any unsuitable proxy's can be thrown away before the next is unmarshalled, allowing garbage collection to clean as you go and prevent memory exhaustion.
>>>
>>> The StreamServiceRegistrar lookup method also takes parameters for Entry classes that are to be unmarshalled for initial filtering, allowing delayed unmarshalling of uninteresting entries.
>>>
>>> Unmarshalling will still be performed by the Registrar implementation, the client just gets to chose when it happens.
>>>
>>> Cheers,
>>>
>>> Peter.
>>>
>>>       
>
>   

Re: StreamServiceRegistrar Was: Re: Jini Activation Framework - A sub project?

[Gregg Wonderly <gr...@gmail.com>]

One of the the things that I played around with was a Protocol handler which would use a URL structure that specified such versioning information.  It would lookup services implementing CodeBaseAccess and ask them if the could provide such a jar file.

This kind of thing makes it easier to deal with some issues about total number of codebase sources, but I am still not sure that it solves the problem you are thinking about.

Gregg Wonderly

Sent from my iPad

On May 5, 2010, at 9:00 PM, Peter Firmstone <ji...@zeus.net.au> wrote:

> The other thing I'm working on is a PackageVersion annotation, using the implementation version and package name from the Java Package Version spec, so developers can version their proxy's allowing sharing of compatible bytecode for reduced codebase downloads.
> 
> I'm hoping that these things combined will assist to enable lookup over the internet.
> 
> Peter Firmstone wrote:
>> Gregg Wonderly wrote:
>>> Many of my service APIs have streaming sockets needed for I/O based activities.  For example, remote event monitoring happens through an ObjectInputStream that is proxied through the smart proxy on the client to a socket end point that the proxy construction provided the details of on the server.
>> 
>> This too is interesting Gregg,  I've done something similar with the StreamServiceRegistrar; I've created a new interface called ResultStream, to mimic an ObjectInputStream, which is returned from lookup.  The idea is to provide a simple interface and minimise network requests by allowing a smart proxy implementation to request and cache larger chunks.  The main advantage of the Stream like behaviour, is to enable incremental filtering stages and delay unmarshalling of proxy's until after initial Entry filtering, then to control the progress of unmarshalling, so your only dealing with one proxy at at time. Further filtering can be performed after each unmarshalling, such as checking method constraints.  Any unsuitable proxy's can be thrown away before the next is unmarshalled, allowing garbage collection to clean as you go and prevent memory exhaustion.
>> 
>> The StreamServiceRegistrar lookup method also takes parameters for Entry classes that are to be unmarshalled for initial filtering, allowing delayed unmarshalling of uninteresting entries.
>> 
>> Unmarshalling will still be performed by the Registrar implementation, the client just gets to chose when it happens.
>> 
>> Cheers,
>> 
>> Peter.
>> 
> 

StreamServiceRegistrar Was: Re: Jini Activation Framework - A sub project?

[Peter Firmstone <ji...@zeus.net.au>]

The other thing I'm working on is a PackageVersion annotation, using the 
implementation version and package name from the Java Package Version 
spec, so developers can version their proxy's allowing sharing of 
compatible bytecode for reduced codebase downloads.

I'm hoping that these things combined will assist to enable lookup over 
the internet.

Peter Firmstone wrote:
> Gregg Wonderly wrote:
>> Many of my service APIs have streaming sockets needed for I/O based 
>> activities.  For example, remote event monitoring happens through an 
>> ObjectInputStream that is proxied through the smart proxy on the 
>> client to a socket end point that the proxy construction provided the 
>> details of on the server.
>
> This too is interesting Gregg,  I've done something similar with the 
> StreamServiceRegistrar; I've created a new interface called 
> ResultStream, to mimic an ObjectInputStream, which is returned from 
> lookup.  The idea is to provide a simple interface and minimise 
> network requests by allowing a smart proxy implementation to request 
> and cache larger chunks.  The main advantage of the Stream like 
> behaviour, is to enable incremental filtering stages and delay 
> unmarshalling of proxy's until after initial Entry filtering, then to 
> control the progress of unmarshalling, so your only dealing with one 
> proxy at at time. Further filtering can be performed after each 
> unmarshalling, such as checking method constraints.  Any unsuitable 
> proxy's can be thrown away before the next is unmarshalled, allowing 
> garbage collection to clean as you go and prevent memory exhaustion.
>
> The StreamServiceRegistrar lookup method also takes parameters for 
> Entry classes that are to be unmarshalled for initial filtering, 
> allowing delayed unmarshalling of uninteresting entries.
>
> Unmarshalling will still be performed by the Registrar implementation, 
> the client just gets to chose when it happens.
>
> Cheers,
>
> Peter.
>

Re: Jini Activation Framework - A sub project?

[Peter Firmstone <ji...@zeus.net.au>]

Gregg Wonderly wrote:
> Many of my service APIs have streaming sockets needed for I/O based 
> activities.  For example, remote event monitoring happens through an 
> ObjectInputStream that is proxied through the smart proxy on the 
> client to a socket end point that the proxy construction provided the 
> details of on the server.

This too is interesting Gregg,  I've done something similar with the 
StreamServiceRegistrar; I've created a new interface called 
ResultStream, to mimic an ObjectInputStream, which is returned from 
lookup.  The idea is to provide a simple interface and minimise network 
requests by allowing a smart proxy implementation to request and cache 
larger chunks.  The main advantage of the Stream like behaviour, is to 
enable incremental filtering stages and delay unmarshalling of proxy's 
until after initial Entry filtering, then to control the progress of 
unmarshalling, so your only dealing with one proxy at at time. Further 
filtering can be performed after each unmarshalling, such as checking 
method constraints.  Any unsuitable proxy's can be thrown away before 
the next is unmarshalled, allowing garbage collection to clean as you go 
and prevent memory exhaustion.

The StreamServiceRegistrar lookup method also takes parameters for Entry 
classes that are to be unmarshalled for initial filtering, allowing 
delayed unmarshalling of uninteresting entries.

Unmarshalling will still be performed by the Registrar implementation, 
the client just gets to chose when it happens.

Cheers,

Peter.

Re: Jini Activation Framework - A sub project?

[Peter Firmstone <ji...@zeus.net.au>]

Thanks Gregg,

I need more of your kind insight into these issues. Very Interesting 
comment about life cycle management and Rio, I wonder if Dennis is 
reading this thread and would like to comment?  An alternative to 
Activation sounds interesting.

Longer term for Java SE, I would like to split jsk-platform.jar, see 
below and remove the coupling of Jini Service Implementations to 
activation, or at least make available some that aren't coupled to it, 
then look at improving Scalability and degradation under load for Reggie.

jsk-platform.jar -less activation.
activation.jar - net.jini.activation.*

I concede your probably right, I need to have a separate Apache River 
Java CDC branch & release.

Even doing so, it should be possible for most if not all jar archives in 
lib-dl to be useable on Java CDC, provided they are compiled with 
source=1.5, target=jsr14 , even if none of the standard Jini services 
run on CDC to begin with, they can be ported later, less activation.

I'm going to need a good build system, so other components can be 
compiled with source=1.5, target=1.5

Cheers,

Peter.

Gregg Wonderly wrote:
> Peter Firmstone wrote:
>> I'm thinking about is how to create the next distribution release 
>> artifacts, namely, creating a platform release artifact that excludes 
>> Activation.  The Java CDC release artifact (zip archive) will be 
>> identical apart from lacking any depreciated classes or methods.
>
> I think that trimming things for the sake of CDC should be focused 
> into a CDC specific spec/artifact-set.  If we splinter the release 
> artifacts that we have today into separate groups, we risk having to 
> do a lot of work to manage the impact this has on existing applications.
>
>> I had figured a Mahalo implementation should be included in the 
>> Apache Release (without Activation), I want to remove the dependency 
>> on Activation being present in the Classpath.  I'll have to do this 
>> for a Java CDC release anyway.
>
> Activation, being used, within the existing pieces of river, as 
> references to the activation framework, does represent an issue.  
> However, are you trying to manage how a CDC client references and uses 
> river artifacts, or are you trying to manage how all of river can 
> compile under CDC limitations?
>
>> Your use of Norm is interesting, I didn't want to include Norm in the 
>> base release.  It sounds like your using Norm to control the 
>> liveliness of your exports, it also sound like these proxy's aren't 
>> registered with the lookup service, tell me more?
>
> If you look at http://pastion.dev.java.net you will see a "PAM" based 
> login mechanism which allows a client to send their login credentials 
> for a particular machine in order to authenticate.  There are now 
> several different products that provide PAM plugins for linux that 
> then utilize some external authentication system such as Active 
> Directory.
>
> My customers wanted to manage access to services using that 
> mechanism.  Pastion has a per call mechanism shown, but I almost 
> always use a "factory" mechanism where the user authenticates and gets 
> back a LeasedSmartProxy subclass.  On the server side, I use 
> java.lang.reflect.InvocationHandler implementations to hook the 
> exported java.lang.reflect.Proxy object into the server.  The 
> LeasedSmartProxy wraps the java.lang.reflect.Proxy and the Lease 
> object and just provides a delegation based implementation of the 
> service interfaces for the client.
>
> Many of my service APIs have streaming sockets needed for I/O based 
> activities.  For example, remote event monitoring happens through an 
> ObjectInputStream that is proxied through the smart proxy on the 
> client to a socket end point that the proxy construction provided the 
> details of on the server.
>
>> My thoughts were:
>>
>>    * A separate release artifact for the Activation Framework.
>>    * Platform release artifacts for Java SE and Java CDC.
>>
>> Your comments are making me think:
>>
>>    * A separate release artifact for the Activation Framework (phoenix,
>>      specific to Java SE).
>>    * Basic platform release artifact (With a very wide platform support
>>      base, one for Java SE 5+, one for Java CDC 1.11).
>>    * One or more Service release artifacts, I want Reggie to take
>>      advantage of the latest java language and concurrency features,
>>      however I want to be able to install other services without
>>      requiring the Activation Framework release to also be installed,
>>      I'm still figuring this bit out.
>
> There are references to the activation framework in the services 
> because they interact with it, rather than being contained by it.  
> Rio, for example shows a way that the lifecycle and deployment 
> constraints can be separated from the service itself.  I don't know if 
> we want to completely separate Activation or if we should just remove 
> the activation framework and make the effort to point at Rio as a 
> lifecycle management system that provides features that manage this 
> issue in a way that allows a simpler POJO kind of service development.
>
> Gregg Wonderly
>
>
>> Cheers,
>>
>> Peter.
>>
>> Gregg Wonderly wrote:
>>> I use norm and mahalo all the time without activation.  I use a 
>>> leased smart proxy instead of DGC so that all of the details of 
>>> proxy management are under my control and I use transactions without 
>>> activation for mahalos lifecycle.
>>>
>>> Gregg wonderly
>>>
>>> Sent from my iPad
>>>
>>> On May 2, 2010, at 8:37 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
>>>
>>>  
>>>> My reasoning for removal from the platform spec or making it 
>>>> optional: Activation is a Service implementation detail.
>>>>
>>>> If there are no objections, I'd like to move it in the near future.
>>>>
>>>> Regards,
>>>>
>>>> Peter.
>>>>
>>>> Peter Firmstone wrote:
>>>>   
>>>>> Can we move the Activation Framework to a subproject of Apache 
>>>>> River?  So it isn't part of the platform?
>>>>>
>>>>> The Activation Framework could be optional and include the following:
>>>>>
>>>>>   * Phoenix - Activation Service
>>>>>   * Norm - Lease Service (This doesn't make much sense outside 
>>>>> Activation)
>>>>>   * Activatable Fiddler - Lookup Discovery Service
>>>>>   * Activatable Reggie - Service Registrar
>>>>>   * Activatable Javaspaces - Outrigger FrontEndSpace.
>>>>>   * Mahalo - Transaction Service (We can create a Non-Activatable
>>>>>     implementation for the platform)
>>>>>   * Mecury - Event mailbox (We can create a Non-Activatable
>>>>>     implementation for the platform)
>>>>>
>>>>> These could be bundled together as an Activation Framework Release
>>>>>
>>>>> Existing interfaces that are specific to Activation in the 
>>>>> net.jini namespace (exclusive of net.jini.activation) could be 
>>>>> depreciated and copied to another package namespace, giving 
>>>>> existing applications time to transition.
>>>>>
>>>>> Then the activation framework becomes something that runs on top 
>>>>> of Jini / Apache River, rather than part of it, making Jini / 
>>>>> River conceptually simpler to new application developers.
>>>>>
>>>>> What are your thoughts?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Peter.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>       
>>>
>>>   
>>
>>
>
>

Re: Jini Activation Framework - A sub project?

[Gregg Wonderly <ge...@cox.net>]

Peter Firmstone wrote:
> I'm thinking about is how to create the next distribution release 
> artifacts, namely, creating a platform release artifact that excludes 
> Activation.  The Java CDC release artifact (zip archive) will be 
> identical apart from lacking any depreciated classes or methods.

I think that trimming things for the sake of CDC should be focused into a CDC 
specific spec/artifact-set.  If we splinter the release artifacts that we have 
today into separate groups, we risk having to do a lot of work to manage the 
impact this has on existing applications.

> I had figured a Mahalo implementation should be included in the Apache 
> Release (without Activation), I want to remove the dependency on 
> Activation being present in the Classpath.  I'll have to do this for a 
> Java CDC release anyway.

Activation, being used, within the existing pieces of river, as references to 
the activation framework, does represent an issue.  However, are you trying to 
manage how a CDC client references and uses river artifacts, or are you trying 
to manage how all of river can compile under CDC limitations?

> Your use of Norm is interesting, I didn't want to include Norm in the 
> base release.  It sounds like your using Norm to control the liveliness 
> of your exports, it also sound like these proxy's aren't registered with 
> the lookup service, tell me more?

If you look at http://pastion.dev.java.net you will see a "PAM" based login 
mechanism which allows a client to send their login credentials for a particular 
machine in order to authenticate.  There are now several different products that 
provide PAM plugins for linux that then utilize some external authentication 
system such as Active Directory.

My customers wanted to manage access to services using that mechanism.  Pastion 
has a per call mechanism shown, but I almost always use a "factory" mechanism 
where the user authenticates and gets back a LeasedSmartProxy subclass.  On the 
server side, I use java.lang.reflect.InvocationHandler implementations to hook 
the exported java.lang.reflect.Proxy object into the server.  The 
LeasedSmartProxy wraps the java.lang.reflect.Proxy and the Lease object and just 
provides a delegation based implementation of the service interfaces for the client.

Many of my service APIs have streaming sockets needed for I/O based activities. 
  For example, remote event monitoring happens through an ObjectInputStream that 
is proxied through the smart proxy on the client to a socket end point that the 
proxy construction provided the details of on the server.

> My thoughts were:
> 
>    * A separate release artifact for the Activation Framework.
>    * Platform release artifacts for Java SE and Java CDC.
> 
> Your comments are making me think:
> 
>    * A separate release artifact for the Activation Framework (phoenix,
>      specific to Java SE).
>    * Basic platform release artifact (With a very wide platform support
>      base, one for Java SE 5+, one for Java CDC 1.11).
>    * One or more Service release artifacts, I want Reggie to take
>      advantage of the latest java language and concurrency features,
>      however I want to be able to install other services without
>      requiring the Activation Framework release to also be installed,
>      I'm still figuring this bit out.

There are references to the activation framework in the services because they 
interact with it, rather than being contained by it.  Rio, for example shows a 
way that the lifecycle and deployment constraints can be separated from the 
service itself.  I don't know if we want to completely separate Activation or if 
we should just remove the activation framework and make the effort to point at 
Rio as a lifecycle management system that provides features that manage this 
issue in a way that allows a simpler POJO kind of service development.

Gregg Wonderly


> Cheers,
> 
> Peter.
> 
> Gregg Wonderly wrote:
>> I use norm and mahalo all the time without activation.  I use a leased 
>> smart proxy instead of DGC so that all of the details of proxy 
>> management are under my control and I use transactions without 
>> activation for mahalos lifecycle.
>>
>> Gregg wonderly
>>
>> Sent from my iPad
>>
>> On May 2, 2010, at 8:37 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
>>
>>  
>>> My reasoning for removal from the platform spec or making it 
>>> optional: Activation is a Service implementation detail.
>>>
>>> If there are no objections, I'd like to move it in the near future.
>>>
>>> Regards,
>>>
>>> Peter.
>>>
>>> Peter Firmstone wrote:
>>>    
>>>> Can we move the Activation Framework to a subproject of Apache 
>>>> River?  So it isn't part of the platform?
>>>>
>>>> The Activation Framework could be optional and include the following:
>>>>
>>>>   * Phoenix - Activation Service
>>>>   * Norm - Lease Service (This doesn't make much sense outside 
>>>> Activation)
>>>>   * Activatable Fiddler - Lookup Discovery Service
>>>>   * Activatable Reggie - Service Registrar
>>>>   * Activatable Javaspaces - Outrigger FrontEndSpace.
>>>>   * Mahalo - Transaction Service (We can create a Non-Activatable
>>>>     implementation for the platform)
>>>>   * Mecury - Event mailbox (We can create a Non-Activatable
>>>>     implementation for the platform)
>>>>
>>>> These could be bundled together as an Activation Framework Release
>>>>
>>>> Existing interfaces that are specific to Activation in the net.jini 
>>>> namespace (exclusive of net.jini.activation) could be depreciated 
>>>> and copied to another package namespace, giving existing 
>>>> applications time to transition.
>>>>
>>>> Then the activation framework becomes something that runs on top of 
>>>> Jini / Apache River, rather than part of it, making Jini / River 
>>>> conceptually simpler to new application developers.
>>>>
>>>> What are your thoughts?
>>>>
>>>> Regards,
>>>>
>>>> Peter.
>>>>
>>>>
>>>>
>>>>
>>>>       
>>
>>   
> 
> 

Re: Jini Activation Framework - A sub project?

[Peter Firmstone <ji...@zeus.net.au>]

Hi Gregg,

I'm thinking about is how to create the next distribution release 
artifacts, namely, creating a platform release artifact that excludes 
Activation.  The Java CDC release artifact (zip archive) will be 
identical apart from lacking any depreciated classes or methods.

I had figured a Mahalo implementation should be included in the Apache 
Release (without Activation), I want to remove the dependency on 
Activation being present in the Classpath.  I'll have to do this for a 
Java CDC release anyway.

Your use of Norm is interesting, I didn't want to include Norm in the 
base release.  It sounds like your using Norm to control the liveliness 
of your exports, it also sound like these proxy's aren't registered with 
the lookup service, tell me more?

My thoughts were:

    * A separate release artifact for the Activation Framework.
    * Platform release artifacts for Java SE and Java CDC.

Your comments are making me think:

    * A separate release artifact for the Activation Framework (phoenix,
      specific to Java SE).
    * Basic platform release artifact (With a very wide platform support
      base, one for Java SE 5+, one for Java CDC 1.11).
    * One or more Service release artifacts, I want Reggie to take
      advantage of the latest java language and concurrency features,
      however I want to be able to install other services without
      requiring the Activation Framework release to also be installed,
      I'm still figuring this bit out.

Cheers,

Peter.

Gregg Wonderly wrote:
> I use norm and mahalo all the time without activation.  I use a leased smart proxy instead of DGC so that all of the details of proxy management are under my control and I use transactions without activation for mahalos lifecycle.
>
> Gregg wonderly
>
> Sent from my iPad
>
> On May 2, 2010, at 8:37 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
>
>   
>> My reasoning for removal from the platform spec or making it optional: Activation is a Service implementation detail.
>>
>> If there are no objections, I'd like to move it in the near future.
>>
>> Regards,
>>
>> Peter.
>>
>> Peter Firmstone wrote:
>>     
>>> Can we move the Activation Framework to a subproject of Apache River?  So it isn't part of the platform?
>>>
>>> The Activation Framework could be optional and include the following:
>>>
>>>   * Phoenix - Activation Service
>>>   * Norm - Lease Service (This doesn't make much sense outside Activation)
>>>   * Activatable Fiddler - Lookup Discovery Service
>>>   * Activatable Reggie - Service Registrar
>>>   * Activatable Javaspaces - Outrigger FrontEndSpace.
>>>   * Mahalo - Transaction Service (We can create a Non-Activatable
>>>     implementation for the platform)
>>>   * Mecury - Event mailbox (We can create a Non-Activatable
>>>     implementation for the platform)
>>>
>>> These could be bundled together as an Activation Framework Release
>>>
>>> Existing interfaces that are specific to Activation in the net.jini namespace (exclusive of net.jini.activation) could be depreciated and copied to another package namespace, giving existing applications time to transition.
>>>
>>> Then the activation framework becomes something that runs on top of Jini / Apache River, rather than part of it, making Jini / River conceptually simpler to new application developers.
>>>
>>> What are your thoughts?
>>>
>>> Regards,
>>>
>>> Peter.
>>>
>>>
>>>
>>>
>>>       
>
>   

Re: Jini Activation Framework - A sub project?

[Peter Firmstone <ji...@zeus.net.au>]

Zsolt Kúti wrote:
> On Mon, 3 May 2010 11:41:58 -0500
> Gregg Wonderly <gr...@gmail.com> wrote:
>
> Hi Gregg,
>
>   
>> I use norm and mahalo all the time without activation.  I use a
>> leased smart proxy instead of DGC so that all of the details of proxy
>>     
> Is there an example for this in any of your public projects?
>
>   
>> management are under my control and I use transactions without
>> activation for mahalos lifecycle.
>>     
> Would you explain this latter sentence, I dont really get it.
>   
Activation means that Mahalo isn't started until it is required, but 
this requires Phoenix to run as a background process.
Mahalo can be constructed to run without activation.

   /**
     * Constructs a non-activatable transaction manager.
     *
     * @param args Service configuration options
     *
     * @param lc <code>LifeCycle</code> reference used for callback
     */
    TxnManagerImpl(String[] args, LifeCycle lc, boolean persistent)
    throws Exception

Re: Jini Activation Framework - A sub project?

[Zsolt Kúti <la...@gmail.com>]

On Tue, 04 May 2010 12:00:38 -0500
Gregg Wonderly <gr...@wonderly.org> wrote:

> Zsolt Kúti wrote:
> > On Mon, 3 May 2010 11:41:58 -0500
> > Gregg Wonderly <gr...@gmail.com> wrote:
> > 
> > Hi Gregg,
> > 
> >> I use norm and mahalo all the time without activation.  I use a
> >> leased smart proxy instead of DGC so that all of the details of
> >> proxy
> 
> > Is there an example for this in any of your public projects?
> 
> http://pastion.dev.java.net has a version of LeasedSmartProxy and
> related classes visible.  It's not well documented, I just pushed it
> out, hoping to get back to cleaning it up.  That hasn't happened...
> 
> >> management are under my control and I use transactions without
> >> activation for mahalos lifecycle.
>  >
> > Would you explain this latter sentence, I dont really get it.
> 
> I just start mahalo using com.sun.jini.start, without activation.
> The use of the Lease in the smart proxy simulates DGCs features.
> There are APIs to listen to the activities of DGC on the server so
> you can see a proxy become unexported. I prefer to get the DGC
> conversation out of the JERI stream that my service interface is
> using.  I've seen cases where DGC has become stuck for long period of
> times doing checks for liveness.  The use of a Lease, for me, unifies
> the use of a feature already available, and it fits into my needs for
> debugging as well, as I can see the lease renewals from the client
> and see the lease renewal fail on the client etc.

Thanks for the link and explanation, Gregg!

Zsolt

Re: Jini Activation Framework - A sub project?

[Gregg Wonderly <gr...@wonderly.org>]

Zsolt Kúti wrote:
> On Mon, 3 May 2010 11:41:58 -0500
> Gregg Wonderly <gr...@gmail.com> wrote:
> 
> Hi Gregg,
> 
>> I use norm and mahalo all the time without activation.  I use a
>> leased smart proxy instead of DGC so that all of the details of proxy

> Is there an example for this in any of your public projects?

http://pastion.dev.java.net has a version of LeasedSmartProxy and related 
classes visible.  It's not well documented, I just pushed it out, hoping to get 
back to cleaning it up.  That hasn't happened...

>> management are under my control and I use transactions without
>> activation for mahalos lifecycle.
 >
> Would you explain this latter sentence, I dont really get it.

I just start mahalo using com.sun.jini.start, without activation.  The use of 
the Lease in the smart proxy simulates DGCs features.  There are APIs to listen 
to the activities of DGC on the server so you can see a proxy become unexported. 
  I prefer to get the DGC conversation out of the JERI stream that my service 
interface is using.  I've seen cases where DGC has become stuck for long period 
of times doing checks for liveness.  The use of a Lease, for me, unifies the use 
of a feature already available, and it fits into my needs for debugging as well, 
as I can see the lease renewals from the client and see the lease renewal fail 
on the client etc.

Gregg Wonderly

Re: Jini Activation Framework - A sub project?

[Zsolt Kúti <la...@gmail.com>]

On Mon, 3 May 2010 11:41:58 -0500
Gregg Wonderly <gr...@gmail.com> wrote:

Hi Gregg,

> I use norm and mahalo all the time without activation.  I use a
> leased smart proxy instead of DGC so that all of the details of proxy
Is there an example for this in any of your public projects?

> management are under my control and I use transactions without
> activation for mahalos lifecycle.
Would you explain this latter sentence, I dont really get it.

Thanks!
Zsolt

Re: Jini Activation Framework - A sub project?

[Gregg Wonderly <gr...@gmail.com>]

I use norm and mahalo all the time without activation.  I use a leased smart proxy instead of DGC so that all of the details of proxy management are under my control and I use transactions without activation for mahalos lifecycle.

Gregg wonderly

Sent from my iPad

On May 2, 2010, at 8:37 PM, Peter Firmstone <ji...@zeus.net.au> wrote:

> My reasoning for removal from the platform spec or making it optional: Activation is a Service implementation detail.
> 
> If there are no objections, I'd like to move it in the near future.
> 
> Regards,
> 
> Peter.
> 
> Peter Firmstone wrote:
>> Can we move the Activation Framework to a subproject of Apache River?  So it isn't part of the platform?
>> 
>> The Activation Framework could be optional and include the following:
>> 
>>   * Phoenix - Activation Service
>>   * Norm - Lease Service (This doesn't make much sense outside Activation)
>>   * Activatable Fiddler - Lookup Discovery Service
>>   * Activatable Reggie - Service Registrar
>>   * Activatable Javaspaces - Outrigger FrontEndSpace.
>>   * Mahalo - Transaction Service (We can create a Non-Activatable
>>     implementation for the platform)
>>   * Mecury - Event mailbox (We can create a Non-Activatable
>>     implementation for the platform)
>> 
>> These could be bundled together as an Activation Framework Release
>> 
>> Existing interfaces that are specific to Activation in the net.jini namespace (exclusive of net.jini.activation) could be depreciated and copied to another package namespace, giving existing applications time to transition.
>> 
>> Then the activation framework becomes something that runs on top of Jini / Apache River, rather than part of it, making Jini / River conceptually simpler to new application developers.
>> 
>> What are your thoughts?
>> 
>> Regards,
>> 
>> Peter.
>> 
>> 
>> 
>> 
> 

Re: Jini Activation Framework - A sub project?

[Peter Firmstone <ji...@zeus.net.au>]

My reasoning for removal from the platform spec or making it optional: 
Activation is a Service implementation detail.

If there are no objections, I'd like to move it in the near future.

Regards,

Peter.

Peter Firmstone wrote:
> Can we move the Activation Framework to a subproject of Apache River?  
> So it isn't part of the platform?
>
> The Activation Framework could be optional and include the following:
>
>    * Phoenix - Activation Service
>    * Norm - Lease Service (This doesn't make much sense outside 
> Activation)
>    * Activatable Fiddler - Lookup Discovery Service
>    * Activatable Reggie - Service Registrar
>    * Activatable Javaspaces - Outrigger FrontEndSpace.
>    * Mahalo - Transaction Service (We can create a Non-Activatable
>      implementation for the platform)
>    * Mecury - Event mailbox (We can create a Non-Activatable
>      implementation for the platform)
>
> These could be bundled together as an Activation Framework Release
>
> Existing interfaces that are specific to Activation in the net.jini 
> namespace (exclusive of net.jini.activation) could be depreciated and 
> copied to another package namespace, giving existing applications time 
> to transition.
>
> Then the activation framework becomes something that runs on top of 
> Jini / Apache River, rather than part of it, making Jini / River 
> conceptually simpler to new application developers.
>
> What are your thoughts?
>
> Regards,
>
> Peter.
>
>
>
>

Jini Activation Framework - A sub project?

[Peter Firmstone <ji...@zeus.net.au>]

Can we move the Activation Framework to a subproject of Apache River?  
So it isn't part of the platform?

The Activation Framework could be optional and include the following:

    * Phoenix - Activation Service
    * Norm - Lease Service (This doesn't make much sense outside Activation)
    * Activatable Fiddler - Lookup Discovery Service
    * Activatable Reggie - Service Registrar
    * Activatable Javaspaces - Outrigger FrontEndSpace.
    * Mahalo - Transaction Service (We can create a Non-Activatable
      implementation for the platform)
    * Mecury - Event mailbox (We can create a Non-Activatable
      implementation for the platform)

These could be bundled together as an Activation Framework Release

Existing interfaces that are specific to Activation in the net.jini 
namespace (exclusive of net.jini.activation) could be depreciated and 
copied to another package namespace, giving existing applications time 
to transition.

Then the activation framework becomes something that runs on top of Jini 
/ Apache River, rather than part of it, making Jini / River conceptually 
simpler to new application developers.

What are your thoughts?

Regards,

Peter.