river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <ge...@cox.net>
Subject Re: Jini Activation Framework - A sub project?
Date Tue, 04 May 2010 15:58:20 GMT
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 <jini@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.

View raw message