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 <[email protected]> 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.
