You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <ji...@zeus.net.au> on 2010/05/04 03:12:51 UTC
Re: Jini Activation Framework - A sub project -edited?
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.
>>>
>>>
>>>
>>>
>>>
>
>