You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2008/11/10 05:50:41 UTC
Re: Future of Jini/River
Taking this on-list, which I perhaps should have done in the first
place. Never-the-less,
On Mon, Nov 10, 2008 at 12:17 AM, Dan Creswell <da...@dcrdev.demon.co.uk> wrote:
> For a long time now, I've been waiting to see a conversation around
> "what next for River". This is something of a good start but....
People don't like to work alone and 'against all odds', so I think all
of River's problems are related to a couple of real problems;
* It is perhaps too complete! Not that many things that is in
desperate need of repairs.
* Overload of Information and Technology Fracture. We have a million
documents, a couple of sites, dozens of related projects that are
spread out and for a newcomer it is unclear what is essential, useful
vs not initially relevant. It is in fact the total opposite of most
projects at Apache.
* Corporate Approach to software distribution. You get something that
you install and use, pretty much like a big fat database, application
server or similar. Modern developers, often test driven and agile, are
not fond of "System Requirements" when writing their own software.
"Check out, compile, run tests" is the motto for many, me included.
For Jini, it means it is hard to create other open source projects
that depends on Jini. The downstream users have to do too much to get
going. This is probably my pet peeve at the moment.
These things are not very concrete. We need to make River more
accessible for non-hardcore Jini users. It must be easy to "see the
light" (samples), "to touch the light" (try yourself) and "follow the
light" (embrace) at a very fundamental level. Jini applications
doesn't live in a vaccuum, the technology must be easier to integrate
into other projects. The hardline view that "we are best and everyone
else should learn from us" ain't gonna cut it.
My own view is that the following areas are first up for review and
rectification;
* Build System. It must be a breeze to build and test River itself.
The current split between tests and source code should IMHO be
eliminated, tests should be executed on all builds, and I think we
should break up the sources into modules instead of a single large
src/ dir with everything in it. If people wants to move towards Maven,
I will support that, primarily since it simplifies artifact
consumption for downstream projects. Same thing can however be
achieved with Ant.
* Right-sizing of the Jini Starter Kit. IMHO, the JSK is a misnomer
unless you intend to write your own Jini implementation of the
Specification services. I think that Apache River could just organize
the whole project better, to get around this problem altogether. I
think we can see a "infrastructure product" separate from the
"developer's tools".
* Configuration System. Although I like it in principle (after all I
was in the JSR-78 EG where it came to light in the first place), BUT
it needs better adjustment to agile and TDD methodologies. Perhaps it
is only a documentation issue, but I have been faced with using
filesystem files to get things going. InputStreams are the way to go.
* Security System. Although extremely important in many scenarios, the
impact on developers for Jini is too big, too soon. Needs to soften
that up in the documentation, which currently deals with experts and
novices alike.
* RMI & JERI, Activatable, Persisten or Transient... Duhhh... Give me
choices that I initially don't care about, and I give you a system
that is booted out from the candidate list. The information around
what each means is overwhelming. I would say that RMI has such
(undeserved IMHO) bad reputation that drop it out of the mainstream,
push JERI as "The Java Binary Communication Layer", and IIRC it is
well suited to have other serialization protocols than std Object
Serialization Streams, which would allow people to experiment, measure
and conclude the true story around serialization (what ever that might
be). So, big tasks in place to make JERI more easily consumable.
* River/Jini 3.0. I think a healthy community needs lofty goals. At
ApacheCon Europe 2008, Roy Fielding was talking about this for Apache
Web Server. He basically called for "next level" of what is possible,
put up serious ambitions and 'screw compatibility' to get there. I
think River could start flowing if some discussion is created along,
"What's the Next Thing?" and see where that leads us. I can imagine
Clouds, Distributed Storage, Network Graph Navigation/Search, new
"Distributed Worker Model", maybe even standard solutions for load
balancing http traffic. Well, I am sure there is a lot to discuss and
dream about. From those dreams come itches, the itches get scratched,
and so on...
All in all, I love Jini, but I think the current situation stinks and
if we (those who care) don't do something really soon, it will be a
blip on the radar of Java history. I can unfortunately NOT be the
driving force behind the technology. First, I lack the know-how
required, and secondly I am tied up in a really large open source
project (http://www.qi4j.org), but where I hope to use Jini/River as a
distribution platform. So I could help out in various areas, just to
make my own situation more bearable (scratch the itch).
Cheers
Niclas
Re: Future of Jini/River
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Fri, Nov 14, 2008 at 4:47 PM, Calum Shaw-Mackay
<ca...@gmail.com> wrote:
> Niclas -
>
> Can you please elaborate on this? I 'd just like to know, I've been
> working with DI concepts using Jini configuration, as well as
> dynamic,event-based reconfiguration through Thor?
>
> Just wondering if this is within the scope that you're thinking of
I have not looked at Thor, but since you mention it I will (once back
at the office desk).
In principle, I would like to see it being dirt easy to deploy and
consume Jini services in a Test Driven environment. That means that
nothing is pre-installed on the computer, it is either in a lib/ dir
and ant, or Maven with artifacts pulled in on demand. It means that
configuration setup is done programmatically and via interfaces that
are type-safe and simple to access. Exactly how this should be done,
is largely due to exactly how the lower level mechanics works, but as
it is now, I don't think it is 'nice enough'...
Cheers
Niclas
>> * Configuration System. Although I like it in principle (after all I
>> was in the JSR-78 EG where it came to light in the first place), BUT
>> it needs better adjustment to agile and TDD methodologies. Perhaps it
>> is only a documentation issue, but I have been faced with using
>> filesystem files to get things going. InputStreams are the way to go.
>
Re: Future of Jini/River
Posted by Sam Chance <sg...@gmail.com>.
Wade, et al,
Jeremy seemed to do a good job of compiling a structured way ahead. I could
be wrong, but I recall no significant response to his idea. I recommend
rallying around Jeremy and implementing his idea.
Sam
On Thu, Nov 20, 2008 at 3:55 PM, Wade Chandler <
hwadechandler-apache@yahoo.com> wrote:
> Where are we? I am very interested in contributing more towards that 3.0
> release or what ever...where it really becomes River and things start anew
> in a sense. I have some NetBeans things I *must* attend to in the near term,
> but certainly would love to help with tooling for NB and some other things.
> What needs to happen for the next release for those bugs which are fixed or
> being fixed to be released as essentially the last bits of incubator
> releases and working towards the main goals of this past conversation?
> Trying to keep the interest moving, but I also have some applications I'll
> be using Jini in the near term :-D
>
> Thanks,
>
> Wade
>
> ==================
> Wade Chandler, CCE
> Software Engineer and Developer, Certified Forensic Computer Examiner,
> NetBeans Dream Team Member, and NetBeans Board Member
> http://www.certified-computer-examiner.com
> http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
> http://www.netbeans.org
>
>
>
> ----- Original Message ----
> > From: Calum Shaw-Mackay <ca...@gmail.com>
> > To: river-dev@incubator.apache.org
> > Sent: Friday, November 14, 2008 10:47:43 AM
> > Subject: Re: Future of Jini/River
> >
> > Niclas -
> >
> > Can you please elaborate on this? I 'd just like to know, I've been
> > working with DI concepts using Jini configuration, as well as
> > dynamic,event-based reconfiguration through Thor?
> >
> > Just wondering if this is within the scope that you're thinking of
> >
> > Cheers
> >
> > Calum
> >
> >
> > > * Configuration System. Although I like it in principle (after all I
> > > was in the JSR-78 EG where it came to light in the first place), BUT
> > > it needs better adjustment to agile and TDD methodologies. Perhaps it
> > > is only a documentation issue, but I have been faced with using
> > > filesystem files to get things going. InputStreams are the way to go.
>
>
--
Sam Chance
443-694-5293 (m)
410-694-0240 x108 (o)
Re: Future of Jini/River
Posted by Wade Chandler <hw...@yahoo.com>.
I suppose this should have been in the other thread "Deciding the future" as it enumerated a lot of things....anyways, point still valid.
Thanks,
Wade
==================
Wade Chandler, CCE
Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team Member, and NetBeans Board Member
http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org
----- Original Message ----
> From: Wade Chandler <hw...@yahoo.com>
> To: river-dev@incubator.apache.org
> Sent: Thursday, November 20, 2008 3:55:27 PM
> Subject: Re: Future of Jini/River
>
> Where are we? I am very interested in contributing more towards that 3.0 release
> or what ever...where it really becomes River and things start anew in a sense. I
> have some NetBeans things I *must* attend to in the near term, but certainly
> would love to help with tooling for NB and some other things. What needs to
> happen for the next release for those bugs which are fixed or being fixed to be
> released as essentially the last bits of incubator releases and working towards
> the main goals of this past conversation? Trying to keep the interest moving,
> but I also have some applications I'll be using Jini in the near term :-D
>
> Thanks,
>
> Wade
>
> ==================
> Wade Chandler, CCE
> Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans
> Dream Team Member, and NetBeans Board Member
> http://www.certified-computer-examiner.com
> http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
> http://www.netbeans.org
>
>
>
> ----- Original Message ----
> > From: Calum Shaw-Mackay
> > To: river-dev@incubator.apache.org
> > Sent: Friday, November 14, 2008 10:47:43 AM
> > Subject: Re: Future of Jini/River
> >
> > Niclas -
> >
> > Can you please elaborate on this? I 'd just like to know, I've been
> > working with DI concepts using Jini configuration, as well as
> > dynamic,event-based reconfiguration through Thor?
> >
> > Just wondering if this is within the scope that you're thinking of
> >
> > Cheers
> >
> > Calum
> >
> >
> > > * Configuration System. Although I like it in principle (after all I
> > > was in the JSR-78 EG where it came to light in the first place), BUT
> > > it needs better adjustment to agile and TDD methodologies. Perhaps it
> > > is only a documentation issue, but I have been faced with using
> > > filesystem files to get things going. InputStreams are the way to go.
Re: Future of Jini/River
Posted by Wade Chandler <hw...@yahoo.com>.
Where are we? I am very interested in contributing more towards that 3.0 release or what ever...where it really becomes River and things start anew in a sense. I have some NetBeans things I *must* attend to in the near term, but certainly would love to help with tooling for NB and some other things. What needs to happen for the next release for those bugs which are fixed or being fixed to be released as essentially the last bits of incubator releases and working towards the main goals of this past conversation? Trying to keep the interest moving, but I also have some applications I'll be using Jini in the near term :-D
Thanks,
Wade
==================
Wade Chandler, CCE
Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team Member, and NetBeans Board Member
http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org
----- Original Message ----
> From: Calum Shaw-Mackay <ca...@gmail.com>
> To: river-dev@incubator.apache.org
> Sent: Friday, November 14, 2008 10:47:43 AM
> Subject: Re: Future of Jini/River
>
> Niclas -
>
> Can you please elaborate on this? I 'd just like to know, I've been
> working with DI concepts using Jini configuration, as well as
> dynamic,event-based reconfiguration through Thor?
>
> Just wondering if this is within the scope that you're thinking of
>
> Cheers
>
> Calum
>
>
> > * Configuration System. Although I like it in principle (after all I
> > was in the JSR-78 EG where it came to light in the first place), BUT
> > it needs better adjustment to agile and TDD methodologies. Perhaps it
> > is only a documentation issue, but I have been faced with using
> > filesystem files to get things going. InputStreams are the way to go.
Re: Future of Jini/River
Posted by Calum Shaw-Mackay <ca...@gmail.com>.
Niclas -
Can you please elaborate on this? I 'd just like to know, I've been
working with DI concepts using Jini configuration, as well as
dynamic,event-based reconfiguration through Thor?
Just wondering if this is within the scope that you're thinking of
Cheers
Calum
> * Configuration System. Although I like it in principle (after all I
> was in the JSR-78 EG where it came to light in the first place), BUT
> it needs better adjustment to agile and TDD methodologies. Perhaps it
> is only a documentation issue, but I have been faced with using
> filesystem files to get things going. InputStreams are the way to go.
Re: Future of Jini/River
Posted by Jeff Ramsdale <je...@gmail.com>.
I'd like to reword Gregg's user experience goal and make it a mantra
for further Apache River development, with apologies to those who've
said it before: "easy things should be easy; hard things should be
possible."
Now I've raised this point at past Jini community meetings and the
feeling I got from core community members was that distributed
applications were by definition hard and thus only REAL software
engineers who paid their dues had any right to use Jini. That's
rubbish. Everybody and their mother is doing cloud computing this and
multi-core that and virtualized messaging infinitely scalable mashups.
People are going to do these things whether they are qualified to or
not. The question is are they going to use Apache River. Right now the
answer is no, though we all know it should be yes.
The other feeling I've gotten from past community meetings is that
Jini/River has no cohesive vision. That is, some people think Jini
(since the conversations were pre-River I'm going to say Jini here) is
a toolkit for building distributed applications and others think it is
a toolkit for building distributed application frameworks. Well which
is it? Who is the Jini audience? Are we meeting their need? In any
case, is there a roadmap? (Answer:
http://incubator.apache.org/river/roadmap.html)
I'm with Niclas--I agree with pretty much everything he said in his
initial post, which echoes Tom Hobbs from the "River-261, namespace
change" thread.
I appreciate Gregg and his work but feel the first steps have to be
baby steps. Let's make the code easy to get, easy to build, easy to
use. Let's post nightly builds. Let's add something to the roadmap
(like maybe a release schedule? And then plan on regular releases...).
Let's ask each of the service container providers (Rio, Seven, etc.)
and the community what their top 3 feature requests are and find the
low-hanging fruit (InputStreams!).
If I can add a second mantra, and this was also mentioned previously:
release early, release often. That's how you bail faster than you
sink. Without a fluid release process there's no way Gregg or Sam or
anyone else can get their contributions even considered and it's
perfectly clear that Apache River will not survive solely on committer
contributions. Please pardon the aquatic references...
-jeff
On Tue, Nov 11, 2008 at 9:53 PM, David Zaffery <za...@gmail.com> wrote:
> Gregg, everyone...
>
> You're last comment cuts to the chase of what River needs to move forward,
> with more acceptance and participation from the community.
>>
>> /I think we have to focus on the user experience and wrap a lot of the
>> mechanics into simple wrappers that don't remove access to the details, but
>> just provide reasonable defaults./
>
> While Jini/River is amazingly great, unless the experience of using it is
> _/drastically improved /_it will never gain momentum and die in incubation.
> The Rails & Grails community follow the code-by-convention paradigm, and
> their acceptance has been very rapid. If all of us who are interested in
> River want it to succeed, then it needs to be made painless to start and use
> just as the Rails/Grails crowd as done. The Servlet versus EJB is another
> example where simple wins the race. Servlets are easy to code, EJBs are
> /perceived/ as not easy...which one is more prevelant today?
>
> I want to be able to use River, but I honestly can't take the chance on
> incorporating in an Enterprise unless there is a community to support it.
> So why not start with Gregg's ideas and roll them in. Focus on the user
> experience make it great. Then River will have something to talk about, and
> could be pushed on InfoQ, TSS, etc....
>
>
> - Dave Zaffery
Re: Future of Jini/River
Posted by Calum Shaw-Mackay <ca...@gmail.com>.
This is one the driving factors behind Glyph - I can build a Jini
service, with an attached (albeit simple) UI and have it deployed in
less than ten minutes.
There is that unwritten "work in 10 minutes or I'm bored" rule with
tech. Jini as a technology is deservedly complex given the problems it
is trying to alleviate, or force the developers to face, and Jini the
'framework' (not a great fan of that word tbh) simply does not exist.
It's like building a pier out to sea and having great structural
supports but putting no decking on top so you can actually walk on it
Calum
2008/11/12 David Zaffery <za...@gmail.com>:
> Gregg, everyone...
>
> You're last comment cuts to the chase of what River needs to move forward,
> with more acceptance and participation from the community.
>>
>> /I think we have to focus on the user experience and wrap a lot of the
>> mechanics into simple wrappers that don't remove access to the details, but
>> just provide reasonable defaults./
>
> While Jini/River is amazingly great, unless the experience of using it is
> _/drastically improved /_it will never gain momentum and die in incubation.
> The Rails & Grails community follow the code-by-convention paradigm, and
> their acceptance has been very rapid. If all of us who are interested in
> River want it to succeed, then it needs to be made painless to start and use
> just as the Rails/Grails crowd as done. The Servlet versus EJB is another
> example where simple wins the race. Servlets are easy to code, EJBs are
> /perceived/ as not easy...which one is more prevelant today?
>
> I want to be able to use River, but I honestly can't take the chance on
> incorporating in an Enterprise unless there is a community to support it.
> So why not start with Gregg's ideas and roll them in. Focus on the user
> experience make it great. Then River will have something to talk about, and
> could be pushed on InfoQ, TSS, etc....
>
>
> - Dave Zaffery
>
>
> Gregg Wonderly wrote:
>>
>> Sam Chance wrote:
>>>
>>> Gregg,
>>>
>>> Please forgive me for what I'm about to say. While all this is surely an
>>> engineering marvel - and perhaps necessary, it has no impact or wow
>>> factor
>>> to motivate 'outsiders' to download, install and use it.
>>
>> Here's my thoughts around this Sam.
>>
>> o New lookup service:
>> Removes the lost codebase problem as an issue because you can pass
>> around the service object in marshalled form. It provides a bases
>> for concepts of marshalled data transmission and use in your service
>> so that you can separate the "container for transport" from the data.
>> In doing that, you provide the opportunity for random marshalling
>> technologies to be used, such as SOAP and other packaging.
>> o Jini Desktop environment:
>> Provides the basis for just install and use services. In concert with
>> getting Seven out the door, there is the opportunity to provide a
>> simple
>> service deployment and use mechanism that would encourage the creation
>> of Jini services. Today, the out of the box experience is raw and full
>> of details that are not "creating the service". I created the stuff
>> in my startnow.dev.java.net project as the mechanism that I use for
>> creating services now. I just do
>>
>> public class MyService extends PersistentJiniService {
>> public static void main( String args[] ) {
>> new MyService( args, null );
>> }
>> public MyService( String args[] ) {
>> super( args );
>> ...get other config params and do setup...
>> startService();
>> }
>> }
>>
>> and I have a Jini service up and running. We need an experience like
>> this where all the config details and all the appropriate defaults just
>> happen for the user. The Seven mechanisms are similar, but the API is
>> richer for plugability and there is the whole deployment mechanism.
>> Password access:
>> We see occasional traffic on the list about "how do I keep joe from
>> using my service if it is visible on the internet?" To me, these hover
>> around the basic issue of how easy it is to do password based
>> authentication using a web interface.
>>
>>
>> I'm all for having some web interface capabilities. For me though, that
>> would be a serviceUI exercise. We would define the appropriate UIDescriptor
>> that would provide all of the details for getting a "servlet" interface to a
>> service. Someone would then just write a service discovery bit for throwing
>> into apache and it would then automatically discover and make available a
>> web service UI to the "world".
>>
>> Proxied Authorization:
>> Using the Java security system is a royal pain because of the issues
>> with how Subject and threads of execution create context that is not
>> always active. So, if you instead use an instance of the service
>> interface as a proxy to the real service, and bury in that proxy,
>> all the authorization implementation, then an existing service can
>> have authorization pasted on top of it without the sprinkling of
>> java security permission checks which pretty much lock you into one
>> mode of authorization. I think this would be a big help to a lot of
>> issues revolving around overall security of network services.
>>
>>> I don't expect to influence the community to make a sharp rudder change,
>>> but
>>> one is sorely needed to bring River from real obscurity to something of
>>> relevance.
>>
>> I think we have to focus on the user experience and wrap a lot of the
>> mechanics into simple wrappers that don't remove access to the details, but
>> just provide reasonable defaults.
>>
>> Gregg Wonderly
>
> --
> All that is necessary for the forces of evil to take root in the world is
> for enough good men to do nothing. -Edmund Burke
>
>
Re: Future of Jini/River
Posted by David Zaffery <za...@gmail.com>.
Gregg, everyone...
You're last comment cuts to the chase of what River needs to move
forward, with more acceptance and participation from the community.
> /I think we have to focus on the user experience and wrap a lot of the
> mechanics into simple wrappers that don't remove access to the
> details, but just provide reasonable defaults./
While Jini/River is amazingly great, unless the experience of using it
is _/drastically improved /_it will never gain momentum and die in
incubation. The Rails & Grails community follow the code-by-convention
paradigm, and their acceptance has been very rapid. If all of us who
are interested in River want it to succeed, then it needs to be made
painless to start and use just as the Rails/Grails crowd as done. The
Servlet versus EJB is another example where simple wins the race.
Servlets are easy to code, EJBs are /perceived/ as not easy...which one
is more prevelant today?
I want to be able to use River, but I honestly can't take the chance on
incorporating in an Enterprise unless there is a community to support
it. So why not start with Gregg's ideas and roll them in. Focus on the
user experience make it great. Then River will have something to talk
about, and could be pushed on InfoQ, TSS, etc....
- Dave Zaffery
Gregg Wonderly wrote:
> Sam Chance wrote:
>> Gregg,
>>
>> Please forgive me for what I'm about to say. While all this is
>> surely an
>> engineering marvel - and perhaps necessary, it has no impact or wow
>> factor
>> to motivate 'outsiders' to download, install and use it.
>
> Here's my thoughts around this Sam.
>
> o New lookup service:
> Removes the lost codebase problem as an issue because you can pass
> around the service object in marshalled form. It provides a bases
> for concepts of marshalled data transmission and use in your service
> so that you can separate the "container for transport" from the data.
> In doing that, you provide the opportunity for random marshalling
> technologies to be used, such as SOAP and other packaging.
> o Jini Desktop environment:
> Provides the basis for just install and use services. In concert
> with
> getting Seven out the door, there is the opportunity to provide a
> simple
> service deployment and use mechanism that would encourage the
> creation
> of Jini services. Today, the out of the box experience is raw and
> full
> of details that are not "creating the service". I created the stuff
> in my startnow.dev.java.net project as the mechanism that I use for
> creating services now. I just do
>
> public class MyService extends PersistentJiniService {
> public static void main( String args[] ) {
> new MyService( args, null );
> }
> public MyService( String args[] ) {
> super( args );
> ...get other config params and do setup...
> startService();
> }
> }
>
> and I have a Jini service up and running. We need an experience like
> this where all the config details and all the appropriate defaults
> just
> happen for the user. The Seven mechanisms are similar, but the
> API is
> richer for plugability and there is the whole deployment mechanism.
> Password access:
> We see occasional traffic on the list about "how do I keep joe from
> using my service if it is visible on the internet?" To me, these
> hover
> around the basic issue of how easy it is to do password based
> authentication using a web interface.
>
>
> I'm all for having some web interface capabilities. For me though,
> that would be a serviceUI exercise. We would define the appropriate
> UIDescriptor that would provide all of the details for getting a
> "servlet" interface to a service. Someone would then just write a
> service discovery bit for throwing into apache and it would then
> automatically discover and make available a web service UI to the
> "world".
>
> Proxied Authorization:
> Using the Java security system is a royal pain because of the issues
> with how Subject and threads of execution create context that is not
> always active. So, if you instead use an instance of the service
> interface as a proxy to the real service, and bury in that proxy,
> all the authorization implementation, then an existing service can
> have authorization pasted on top of it without the sprinkling of
> java security permission checks which pretty much lock you into one
> mode of authorization. I think this would be a big help to a lot of
> issues revolving around overall security of network services.
>
>> I don't expect to influence the community to make a sharp rudder
>> change, but
>> one is sorely needed to bring River from real obscurity to something of
>> relevance.
>
> I think we have to focus on the user experience and wrap a lot of the
> mechanics into simple wrappers that don't remove access to the
> details, but just provide reasonable defaults.
>
> Gregg Wonderly
--
All that is necessary for the forces of evil to take root in the world is for enough good men to do nothing. -Edmund Burke
Re: Future of Jini/River
Posted by Gregg Wonderly <ge...@cox.net>.
Sam Chance wrote:
> Why couldn't Jini explicitly address the service discovery challenges
> currently prominent in mainstream SOA? Why can't I log into my machine and
> see available services pushed to me - perhaps filtered by security, roles,
> interests, etc? I don't care where they are; I just want to use them.
My Jini desktop does just this. It uses a more simplified security mechanism,
while still providing some security. You have a file of hosts and a file of URL
suffixes. The union of all of combinations of those are granted AllPermission.
There is also the one giant thing, for me, which I have addressed in my
implementation of "no downloads until the user clicks". If discovery continues
to work the way it does now, then imagine waiting for the entire internet to
download onto your computer before you could access anything. That's what
happens with discovery today, when used in the simple case of a template such as
ServiceTemplate t = new ServiceTemplate( null, null,
new Entry[] { UIDescriptor.class });
that you'd use to find all services that provided a ServiceUI.
For me, this is one of the very large issues. Now there are, of course all
kinds of selections that can be made in the ServiceTemplate. But still, some VM
on some machine, somewhere, has to download and unmarshall every service found...
Gregg Wonderly
Re: Future of Jini/River
Posted by Dan Creswell <da...@dcrdev.demon.co.uk>.
Hi Sam,
Sam Chance wrote:
> All,
>
> Many of you may be familiar with companies like GlobalInfoTek and Paremus.
> GlobalInfoTek has implemented a capability called "Intelligent Services
> Layer" (ISL) and a composition layer on top of it called CHAIN. You can go
> to their website to learn more.
>
> Paremus has built a distributed services framework that manages OSGi bundles
> (components) and assembles them into systems using a Service Component
> Architecture (SCA) based model.
>
> Both of these feature the various autonomic properties provided by
> Jini...and more. They're awesome and we never have to talk about Jini.
>
Do you ever talk about River?
> Then we have "SOA". I suppose we've bemoaned the fact that XML Web Services
> don't = SOA and vice verse. However, SOAP/WSDL and REST/WADL remain all the
> rage. I always argue we have JBOWS and not SOA. (Just a Bunch of Web
> Services). But I doubt anyone cares! :-)
>
They're all the rage for various reasons - which might include:
(1) SOAP/WSDL is basically CORBA or a subset of RMI - it's a simple
leap for most and allows them to not worry about failure as they have
always done before. New technology same old philosophical approach to
design.
(2) REST arguably didn't really take off until it got first class
support (of a sort) in Ruby on Rails. Around the same time many
websites had some sort of API available over http and all claimed they
were RESTful which got everybody's interest although in many cases these
APIs weren't even remotely inline with the basics of REST. Even now
exactly what complete REST might be is something of an exercise left to
the reader to discover. There are lots of dark corners design-wise and
most http libraries make it somewhat difficult to do well.
> Still, the static nature of mainstream SOA presents *yet another*
> opportunity for Jini/River to emerge as relevant. For example, service
> discovery is some pathetic attempt to register service descriptions in a
> UDDI. Nobody uses or likes UDDI. Well, I'm sure someone does. :)
>
> As another example, I recently attended a "No Fluff, Just Stuff" conference
> wherein the speaker was talking about REST and Resource Oriented
> Architecture. In his talk, he showed an example of (location independent)
> service discovery. His discovery mechanism? JMDNS (jmdns.sourceforge.net).
> I asked him if he heard of Jini and, if so, what he thought of it. His
> answer: Yes. It's too complicated and overkill. He's a smart, well informed
> technology leader and HE doesn't appreciate Jini!
>
Ah but he does appreciate Jini - that's why he's using JMDNS. JMDNS is
one small chunk of the Jini philosophy. It's a dynamic discovery mechanism.
To sell to this guy means getting him to take another step - it might be
code-downloading (if we make it work nice) or security or.......
Jini of course does what JMDNS does but requires at least potentially a
few more steps beyond what you'd do for a JMDNS app like building up
download .jars and the like. None of the documentation I've seen tells
a developer "how to build a JMDNS-like app with Jini".....
> Why couldn't Jini explicitly address the service discovery challenges
> currently prominent in mainstream SOA? Why can't I log into my machine and
What is mainstream SOA? There are seemingly 90000 meanings and
definitions as supplied by the endless list of "SOA-compliant" vendors.
Much of the "service discovery" I've seen in this arena is in the style
of CORBA or similar staticness. It's not nearly as "compatible" as
JMDNS and thus a harder step to take.
> see available services pushed to me - perhaps filtered by security, roles,
> interests, etc? I don't care where they are; I just want to use them.
>
You can but it wouldn't fit with how most SOA people think it should work.
> Why can't we do discovery over the Internet? At least an Enterprise
> Intranet?
>
Intranet != Internet.
On an intranet you have a cat in hells chance of mulicast working though
most network admins won't enable it out of some fear or another.
However discovery can be done on the internet already with appropriate
open ports and peering of lookup services. However:
(1) Your firewall/network admins have to be prepared to co-operate and
potentially open up more than port 80.
(2) You need to put the appropriate configuration magic into your
lookup services and services.
But what you don't get out of this is the more flexible
lower-configuration discovery that comes from multicast.
> I would (almost) bet money that various Jini/River-based projects (currently
> floundering in obscurity) address or begin to address these challenges /
> needs?
>
> I think we ought to confront the reality that technology does not
> necessarily rise to large-scale adoption based on merits, but ease of
> understanding and ease of use and marketing. In fact, I've heard folks
> nicely describe the process as "Awareness, Appreciation, then Preference."
>
> River lacks the first two, and thus never makes it to the third. The
> "River" community arguably is "balkanized". Each time this issue comes up,
> a group of VERY smart technologists/engineers talks about things like
> "serialization, marshaling, interfaces, namespaces..." and all manner of
> deep, into the weeds, technical jargon. But there is no coordinated effort
> to simplify, educate and evangelize. No vision will lead to its eventual
> death.
>
> I constantly bring up Jini, and the aforementioned companies, in my circles,
> and I get the same results: Ignorance and apathy.
>
> If we can't rally around a couple of relevant uses and we if we can't
> simplify it and if we can't (then) spread the gospel, then we'll not create
> Awareness that leads to Appreciation and ultimately Preference.
>
> There is simply no way I can successfully evangelize Jini by telling people
> it is a "...dynamic, distributed SOA framework..." The recipient perceives
> that as a gnat on a horse's ass. They're going to ride the horse and not
> even realize there's a gnat on it!
>
> Since I learned about Jini in 2001, I've been a big fan. I see incredible
> uses that scale from services within a machine up to planes, trains, and
> automobiles... worldwide! :-)
>
> Sorry for the rant...
> Sam
>
>
>
>
>
> On Tue, Nov 11, 2008 at 9:22 AM, Gregg Wonderly <gr...@wonderly.org> wrote:
>
>> Sam Chance wrote:
>>
>>> Gregg,
>>>
>>> Please forgive me for what I'm about to say. While all this is surely an
>>> engineering marvel - and perhaps necessary, it has no impact or wow factor
>>> to motivate 'outsiders' to download, install and use it.
>>>
>> Here's my thoughts around this Sam.
>>
>> o New lookup service:
>> Removes the lost codebase problem as an issue because you can pass
>> around the service object in marshalled form. It provides a bases
>> for concepts of marshalled data transmission and use in your service
>> so that you can separate the "container for transport" from the
>> data.
>> In doing that, you provide the opportunity for random marshalling
>> technologies to be used, such as SOAP and other packaging.
>> o Jini Desktop environment:
>> Provides the basis for just install and use services. In concert
>> with
>> getting Seven out the door, there is the opportunity to provide a
>> simple
>> service deployment and use mechanism that would encourage the
>> creation
>> of Jini services. Today, the out of the box experience is raw and
>> full
>> of details that are not "creating the service". I created the stuff
>> in my startnow.dev.java.net project as the mechanism that I use for
>> creating services now. I just do
>>
>> public class MyService extends PersistentJiniService {
>> public static void main( String args[] ) {
>> new MyService( args, null );
>> }
>> public MyService( String args[] ) {
>> super( args );
>> ...get other config params and do setup...
>> startService();
>> }
>> }
>>
>> and I have a Jini service up and running. We need an experience
>> like
>> this where all the config details and all the appropriate defaults
>> just
>> happen for the user. The Seven mechanisms are similar, but the API
>> is
>> richer for plugability and there is the whole deployment mechanism.
>> Password access:
>> We see occasional traffic on the list about "how do I keep joe from
>> using my service if it is visible on the internet?" To me, these
>> hover
>> around the basic issue of how easy it is to do password based
>> authentication using a web interface.
>>
>>
>> I'm all for having some web interface capabilities. For me though, that
>> would be a serviceUI exercise. We would define the appropriate UIDescriptor
>> that would provide all of the details for getting a "servlet" interface to a
>> service. Someone would then just write a service discovery bit for throwing
>> into apache and it would then automatically discover and make available a
>> web service UI to the "world".
>>
>> Proxied Authorization:
>> Using the Java security system is a royal pain because of the issues
>> with how Subject and threads of execution create context that is not
>> always active. So, if you instead use an instance of the service
>> interface as a proxy to the real service, and bury in that proxy,
>> all the authorization implementation, then an existing service can
>> have authorization pasted on top of it without the sprinkling of
>> java security permission checks which pretty much lock you into one
>> mode of authorization. I think this would be a big help to a lot of
>> issues revolving around overall security of network services.
>>
>> I don't expect to influence the community to make a sharp rudder change,
>>> but
>>> one is sorely needed to bring River from real obscurity to something of
>>> relevance.
>>>
>> I think we have to focus on the user experience and wrap a lot of the
>> mechanics into simple wrappers that don't remove access to the details, but
>> just provide reasonable defaults.
>>
>> Gregg Wonderly
>>
>
Re: Future of Jini/River
Posted by Wade Chandler <hw...@yahoo.com>.
----- Original Message ----
> From: Sam Chance <sg...@gmail.com>
> To: river-dev@incubator.apache.org
> Sent: Friday, November 14, 2008 8:52:30 PM
> Subject: Re: Future of Jini/River
>
> All,
>
> Many of you may be familiar with companies like GlobalInfoTek and Paremus.
> GlobalInfoTek has implemented a capability called "Intelligent Services
> Layer" (ISL) and a composition layer on top of it called CHAIN. You can go
> to their website to learn more.
>
> Paremus has built a distributed services framework that manages OSGi bundles
> (components) and assembles them into systems using a Service Component
> Architecture (SCA) based model.
>
> Both of these feature the various autonomic properties provided by
> Jini...and more. They're awesome and we never have to talk about Jini.
>
Seems with significatn differences in memory requirements, OS targets, and as far as I can tell application targets/markets. Always more to read though.
> Then we have "SOA". I suppose we've bemoaned the fact that XML Web Services
> don't = SOA and vice verse. However, SOAP/WSDL and REST/WADL remain all the
> rage. I always argue we have JBOWS and not SOA. (Just a Bunch of Web
> Services). But I doubt anyone cares! :-)
>
> Still, the static nature of mainstream SOA presents *yet another*
> opportunity for Jini/River to emerge as relevant. For example, service
> discovery is some pathetic attempt to register service descriptions in a
> UDDI. Nobody uses or likes UDDI. Well, I'm sure someone does. :)
>
UDDI has it's place. Just like JMDNS below. These are all targeting different problems necessarily. I have seen you use irrelevant for describing Jini a couple times. My view is it is very relevant in its current form just maybe not as popular or well known, which may be your meaning, but it isn't a model one would use in every application nor is it related to web services necessarily, nor is it really understood by many. I would argue the same thing about Java EE and EJB. Not understanding something doesn't mean the issue it solves isn't relevant nor is it wrong at the base layer in the overall approach to solving the problem, but don't let that confuse the issue that things can always be made simpler such as deployment or installation and embedding etc.
Realizing no one needs a course on WS, XML web services are all about interoperability and single point RPC and data transfer; at least this is their initial design, and this is why we now see REST and different remoting protocols for things to try to make these things more performant as they were not designed to be used the way they are actually being used today as full blown application support, and is why RMI and other things still have their place versus XML web services. I feel most of these technologies have been a little misused for the sake of heterogenious front ends at the expense of performance, or in the case of RMI at times, used for data transfer at the expense of heterogenious data access calls; at least this is the only way I can explain the constant shift in patterns as it relates to them JAX-RPC, JAX-WS, *-RS, what's next :-). Jini as I see it is about performance driven distributed discoverable services which provides not only
services, in the sense different from web services, but distributed and concurrent memory through JavaSpaces. A totally differnet technology though solving some of the same issues.
Now, if there is a market for such support under the hood, to operate over SOAP and web services, but not as the default or main reason for Jini's being, then I don't think that is a bad thing necesarily. The transport layer is already pluggable, but to me really, the only thing that solves, as services are not defined in something like WSDL but instead interfaces etc, and that seems that would just be a whole lot of work to not necessarily solve the real issues with Jini at the moment which seem more related to learning curves and not the technology itself except for those things listed as needing to be addressed. Folks are using Rio and like and they seem to find most useful the general concepts of Jini because they solve unique problems really. As it relates to web services or any other kind of service, and as it relates to Java per the nature of Jini, I think Jini could be used to locate or integrate about anything.
> As another example, I recently attended a "No Fluff, Just Stuff" conference
> wherein the speaker was talking about REST and Resource Oriented
> Architecture. In his talk, he showed an example of (location independent)
> service discovery. His discovery mechanism? JMDNS (jmdns.sourceforge.net).
> I asked him if he heard of Jini and, if so, what he thought of it. His
> answer: Yes. It's too complicated and overkill. He's a smart, well informed
> technology leader and HE doesn't appreciate Jini!
>
Again I argue solving different problems here. Jini isn't WS nor REST, and the discovery mechanisms in Jini, through interfaces and remote downloadable code, are more descriptive and powerful than what DNS Srv and multicast DNS (JMDNS) is trying to solve. JMDNS tells you where a given service is by protocol and what port where as Jini gives you the services and they can use what ever kinds of proxies and interfaces they have been programmed to use and then system administrators need to follow whatever documentation is available for those services such as open ports XYZ on firewalls and routers etc.
Take my Dell 1720dn printers. The driver is installed by a disk, and is running in the OS as an OS level service as a printer driver. It then communicates on the ports the service in the printer is configured. I have to configure my network or them to deal with the situation depending on my needs. Jini works on this level except the device or remote services remotely install their own code through the service versus a driver disk. This can be in a desktop or server computer or on some other small type device which can implement the Jini protocols and class interfaces etc. This is a little different than DNS level services or service by name or protocol. Suttle from a birds eye view, but very different at the implementation and problem/domain level.
> Why couldn't Jini explicitly address the service discovery challenges
> currently prominent in mainstream SOA? Why can't I log into my machine and
> see available services pushed to me - perhaps filtered by security, roles,
> interests, etc? I don't care where they are; I just want to use them.
>
Pretty much Jini solves this although not through a UI of some sort, but instead for other applications through API. Now, the security stuff I'm not all sure about yet, but you can do that for sure. It would be very easy to filter per roles and security as long as the services you have coded are using some kind of interface and you can ask them if you have rights to use them etc based on some credential. I don't really know what is and isn't supported at the Jini level as it relates to security other than building it in yourself, but this is one of the things which has been talked about addressing in the thread where a list of wants and needs was listed.
> Why can't we do discovery over the Internet? At least an Enterprise
> Intranet?
>
There isn't anything keeping Jini from working on a broader network now that I know of. Routers need to be configured to forward multicast packets. Over the internet can be an issue because of packet delivery etc. Many ISPs won't support multicast. This is where Unicast comes in handy.
> I would (almost) bet money that various Jini/River-based projects (currently
> floundering in obscurity) address or begin to address these challenges /
> needs?
>
Sure. This happens with anything solving harder problems. This is the exact same thing with Spring, Hibernate, and others as it relates to JEE, and look at the ideas which have been moving into JEE over the passed two iterations (one in the works 6). That makes the core standards and ideas better. There has to be some central ideas for other things to build atop. Had there not been JavaBeans would Spring look the same today? I doubt it. What about JEE? What if JEE didn't exist? Then would Spring exist? If so, then where would the standards related to clustering and session replication have come, what about those central ideas? This is the nature of the business yet folks tend to forget it and not see it, and is why JEE tends to get a bad rap too, and folks forget all the problems JEE solves such as clustering, session replication, distributed and remote services and data, transactions, and scheduling.
> I think we ought to confront the reality that technology does not
> necessarily rise to large-scale adoption based on merits, but ease of
> understanding and ease of use and marketing. In fact, I've heard folks
> nicely describe the process as "Awareness, Appreciation, then Preference."
>
Here I point to my last paragraph how things build on top of other things. At the heart of Jini is a pretty unique problem solving solution; similar here and there to other things yet not the same. That core value is there. Now, making that core value easier to use and more approachable/adoptable shouldn't limit what it can do, but should merely allow a set of abstractions which make it easier yet do not get in the way when one needs to get low level with the technology. I have used different APIs in different technologies and environments which could have been much better if there hadn't been too much hand holding without exposing the hairy details if needed, and those things are fine when the problem you solve is simple, but when it gets complex it is better to have the details in the open so that one can become an expert and get the most from the system.
> River lacks the first two, and thus never makes it to the third. The
> "River" community arguably is "balkanized". Each time this issue comes up,
> a group of VERY smart technologists/engineers talks about things like
> "serialization, marshaling, interfaces, namespaces..." and all manner of
> deep, into the weeds, technical jargon. But there is no coordinated effort
> to simplify, educate and evangelize. No vision will lead to its eventual
> death.
>
> I constantly bring up Jini, and the aforementioned companies, in my circles,
> and I get the same results: Ignorance and apathy.
>
> If we can't rally around a couple of relevant uses and we if we can't
> simplify it and if we can't (then) spread the gospel, then we'll not create
> Awareness that leads to Appreciation and ultimately Preference.
>
I don't want to beat a dead horse, but I feel it would be useless to simplify or as has been said to dumb down the technology. It has to be kept in mind that the capabilities do not need to be simplified except where it might improve them, but some abstractions and fluff needs to be added to simplify the technology. No fluff is great when a problem is as easy as REST or a single connection to a single point or asking something where something is in a very generic sense, but Jini solves more technical and difficult problems. I'm all for simplification where it needs to be done, but not at the expense of functionality, and I think you can get both with abstractions, build systems, installers, tooling etc, for making things more approachable for beginners and intermediate use, but those at the top of the food chain are not going to find use in the technology if overall things are simplified and dumb downed. In that regard I don't think it is possible, and
folks need to realize the differences in the problems being solved by the different technologies being talked about and not just the differences in the technologies.
I agree some uses need to be detailed and some applicability needs to be demonstrated for folks to see. I too agree that it needs to be more approachable, but I think that is best handled through abstractions and tooling leaving the capabilities intact. Too, the web site and advertising the technology is important.
> There is simply no way I can successfully evangelize Jini by telling people
> it is a "...dynamic, distributed SOA framework..." The recipient perceives
> that as a gnat on a horse's ass. They're going to ride the horse and not
> even realize there's a gnat on it!
>
Yes, and this is where examples can help. Examples from different walks of life. Jini can be used for simple things such as:
*) Service to lookup databases, servers, and ports for data access in a relaxed client server model applications.
*) Service to locate web services of a given type within a network.
*) Service to lookup and load code which embeds libraries to access the server layer of strict client server model applications.
and for more complicated things:
*) Service to lookup and operate on premises cameras.
*) Service to lookup and monitor different security systems and devices on premises.
*) Service to lookup and manage different on board sensors on a car or other transportation machine.
*) Service to lookup and access RFID readers.
and of course both lists can go on and on. I believe some good and simple examples can be created for the application level support. Some of the others can be done as well but depending on those examples where hardware is involved more expense can be involved, so those have to be studied more closely to see who wants to do them or what can be done cheaply and show off what can be done.
> Since I learned about Jini in 2001, I've been a big fan. I see incredible
> uses that scale from services within a machine up to planes, trains, and
> automobiles... worldwide! :-)
>
Yes! I guess I get a little confused as you bring up Web Services and REST. Do you mean support those things in tandem or what exactly? Do you mean more example uses of Jini using these technologies? Do you mean to change Jini to use these technologies instead of the way services and logic are downloaded now?
Wade
Re: Future of Jini/River
Posted by Sam Chance <sg...@gmail.com>.
All,
Many of you may be familiar with companies like GlobalInfoTek and Paremus.
GlobalInfoTek has implemented a capability called "Intelligent Services
Layer" (ISL) and a composition layer on top of it called CHAIN. You can go
to their website to learn more.
Paremus has built a distributed services framework that manages OSGi bundles
(components) and assembles them into systems using a Service Component
Architecture (SCA) based model.
Both of these feature the various autonomic properties provided by
Jini...and more. They're awesome and we never have to talk about Jini.
Then we have "SOA". I suppose we've bemoaned the fact that XML Web Services
don't = SOA and vice verse. However, SOAP/WSDL and REST/WADL remain all the
rage. I always argue we have JBOWS and not SOA. (Just a Bunch of Web
Services). But I doubt anyone cares! :-)
Still, the static nature of mainstream SOA presents *yet another*
opportunity for Jini/River to emerge as relevant. For example, service
discovery is some pathetic attempt to register service descriptions in a
UDDI. Nobody uses or likes UDDI. Well, I'm sure someone does. :)
As another example, I recently attended a "No Fluff, Just Stuff" conference
wherein the speaker was talking about REST and Resource Oriented
Architecture. In his talk, he showed an example of (location independent)
service discovery. His discovery mechanism? JMDNS (jmdns.sourceforge.net).
I asked him if he heard of Jini and, if so, what he thought of it. His
answer: Yes. It's too complicated and overkill. He's a smart, well informed
technology leader and HE doesn't appreciate Jini!
Why couldn't Jini explicitly address the service discovery challenges
currently prominent in mainstream SOA? Why can't I log into my machine and
see available services pushed to me - perhaps filtered by security, roles,
interests, etc? I don't care where they are; I just want to use them.
Why can't we do discovery over the Internet? At least an Enterprise
Intranet?
I would (almost) bet money that various Jini/River-based projects (currently
floundering in obscurity) address or begin to address these challenges /
needs?
I think we ought to confront the reality that technology does not
necessarily rise to large-scale adoption based on merits, but ease of
understanding and ease of use and marketing. In fact, I've heard folks
nicely describe the process as "Awareness, Appreciation, then Preference."
River lacks the first two, and thus never makes it to the third. The
"River" community arguably is "balkanized". Each time this issue comes up,
a group of VERY smart technologists/engineers talks about things like
"serialization, marshaling, interfaces, namespaces..." and all manner of
deep, into the weeds, technical jargon. But there is no coordinated effort
to simplify, educate and evangelize. No vision will lead to its eventual
death.
I constantly bring up Jini, and the aforementioned companies, in my circles,
and I get the same results: Ignorance and apathy.
If we can't rally around a couple of relevant uses and we if we can't
simplify it and if we can't (then) spread the gospel, then we'll not create
Awareness that leads to Appreciation and ultimately Preference.
There is simply no way I can successfully evangelize Jini by telling people
it is a "...dynamic, distributed SOA framework..." The recipient perceives
that as a gnat on a horse's ass. They're going to ride the horse and not
even realize there's a gnat on it!
Since I learned about Jini in 2001, I've been a big fan. I see incredible
uses that scale from services within a machine up to planes, trains, and
automobiles... worldwide! :-)
Sorry for the rant...
Sam
On Tue, Nov 11, 2008 at 9:22 AM, Gregg Wonderly <gr...@wonderly.org> wrote:
> Sam Chance wrote:
>
>> Gregg,
>>
>> Please forgive me for what I'm about to say. While all this is surely an
>> engineering marvel - and perhaps necessary, it has no impact or wow factor
>> to motivate 'outsiders' to download, install and use it.
>>
>
> Here's my thoughts around this Sam.
>
> o New lookup service:
> Removes the lost codebase problem as an issue because you can pass
> around the service object in marshalled form. It provides a bases
> for concepts of marshalled data transmission and use in your service
> so that you can separate the "container for transport" from the
> data.
> In doing that, you provide the opportunity for random marshalling
> technologies to be used, such as SOAP and other packaging.
> o Jini Desktop environment:
> Provides the basis for just install and use services. In concert
> with
> getting Seven out the door, there is the opportunity to provide a
> simple
> service deployment and use mechanism that would encourage the
> creation
> of Jini services. Today, the out of the box experience is raw and
> full
> of details that are not "creating the service". I created the stuff
> in my startnow.dev.java.net project as the mechanism that I use for
> creating services now. I just do
>
> public class MyService extends PersistentJiniService {
> public static void main( String args[] ) {
> new MyService( args, null );
> }
> public MyService( String args[] ) {
> super( args );
> ...get other config params and do setup...
> startService();
> }
> }
>
> and I have a Jini service up and running. We need an experience
> like
> this where all the config details and all the appropriate defaults
> just
> happen for the user. The Seven mechanisms are similar, but the API
> is
> richer for plugability and there is the whole deployment mechanism.
> Password access:
> We see occasional traffic on the list about "how do I keep joe from
> using my service if it is visible on the internet?" To me, these
> hover
> around the basic issue of how easy it is to do password based
> authentication using a web interface.
>
>
> I'm all for having some web interface capabilities. For me though, that
> would be a serviceUI exercise. We would define the appropriate UIDescriptor
> that would provide all of the details for getting a "servlet" interface to a
> service. Someone would then just write a service discovery bit for throwing
> into apache and it would then automatically discover and make available a
> web service UI to the "world".
>
> Proxied Authorization:
> Using the Java security system is a royal pain because of the issues
> with how Subject and threads of execution create context that is not
> always active. So, if you instead use an instance of the service
> interface as a proxy to the real service, and bury in that proxy,
> all the authorization implementation, then an existing service can
> have authorization pasted on top of it without the sprinkling of
> java security permission checks which pretty much lock you into one
> mode of authorization. I think this would be a big help to a lot of
> issues revolving around overall security of network services.
>
> I don't expect to influence the community to make a sharp rudder change,
>> but
>> one is sorely needed to bring River from real obscurity to something of
>> relevance.
>>
>
> I think we have to focus on the user experience and wrap a lot of the
> mechanics into simple wrappers that don't remove access to the details, but
> just provide reasonable defaults.
>
> Gregg Wonderly
>
Re: Future of Jini/River
Posted by Dan Rollo <da...@gmail.com>.
+1, and any of this that can make it into River (and not have to be
Seven specific) sure sounds good to me.
Dan
Gregg Wonderly wrote:
> Sam Chance wrote:
>> Gregg,
>>
>> Please forgive me for what I'm about to say. While all this is surely an
>> engineering marvel - and perhaps necessary, it has no impact or wow
>> factor
>> to motivate 'outsiders' to download, install and use it.
>
> Here's my thoughts around this Sam.
>
> o New lookup service:
> Removes the lost codebase problem as an issue because you can pass
> around the service object in marshalled form. It provides a bases
> for concepts of marshalled data transmission and use in your service
> so that you can separate the "container for transport" from the data.
> In doing that, you provide the opportunity for random marshalling
> technologies to be used, such as SOAP and other packaging.
> o Jini Desktop environment:
> Provides the basis for just install and use services. In concert with
> getting Seven out the door, there is the opportunity to provide a
> simple
> service deployment and use mechanism that would encourage the creation
> of Jini services. Today, the out of the box experience is raw and full
> of details that are not "creating the service". I created the stuff
> in my startnow.dev.java.net project as the mechanism that I use for
> creating services now. I just do
>
> public class MyService extends PersistentJiniService {
> public static void main( String args[] ) {
> new MyService( args, null );
> }
> public MyService( String args[] ) {
> super( args );
> ...get other config params and do setup...
> startService();
> }
> }
>
> and I have a Jini service up and running. We need an experience like
> this where all the config details and all the appropriate defaults just
> happen for the user. The Seven mechanisms are similar, but the API is
> richer for plugability and there is the whole deployment mechanism.
> Password access:
> We see occasional traffic on the list about "how do I keep joe from
> using my service if it is visible on the internet?" To me, these hover
> around the basic issue of how easy it is to do password based
> authentication using a web interface.
>
>
> I'm all for having some web interface capabilities. For me though, that
> would be a serviceUI exercise. We would define the appropriate
> UIDescriptor that would provide all of the details for getting a
> "servlet" interface to a service. Someone would then just write a
> service discovery bit for throwing into apache and it would then
> automatically discover and make available a web service UI to the "world".
>
> Proxied Authorization:
> Using the Java security system is a royal pain because of the issues
> with how Subject and threads of execution create context that is not
> always active. So, if you instead use an instance of the service
> interface as a proxy to the real service, and bury in that proxy,
> all the authorization implementation, then an existing service can
> have authorization pasted on top of it without the sprinkling of
> java security permission checks which pretty much lock you into one
> mode of authorization. I think this would be a big help to a lot of
> issues revolving around overall security of network services.
>
>> I don't expect to influence the community to make a sharp rudder
>> change, but
>> one is sorely needed to bring River from real obscurity to something of
>> relevance.
>
> I think we have to focus on the user experience and wrap a lot of the
> mechanics into simple wrappers that don't remove access to the details,
> but just provide reasonable defaults.
>
> Gregg Wonderly
Re: Future of Jini/River
Posted by Gregg Wonderly <gr...@wonderly.org>.
Sam Chance wrote:
> Gregg,
>
> Please forgive me for what I'm about to say. While all this is surely an
> engineering marvel - and perhaps necessary, it has no impact or wow factor
> to motivate 'outsiders' to download, install and use it.
Here's my thoughts around this Sam.
o New lookup service:
Removes the lost codebase problem as an issue because you can pass
around the service object in marshalled form. It provides a bases
for concepts of marshalled data transmission and use in your service
so that you can separate the "container for transport" from the data.
In doing that, you provide the opportunity for random marshalling
technologies to be used, such as SOAP and other packaging.
o Jini Desktop environment:
Provides the basis for just install and use services. In concert with
getting Seven out the door, there is the opportunity to provide a simple
service deployment and use mechanism that would encourage the creation
of Jini services. Today, the out of the box experience is raw and full
of details that are not "creating the service". I created the stuff
in my startnow.dev.java.net project as the mechanism that I use for
creating services now. I just do
public class MyService extends PersistentJiniService {
public static void main( String args[] ) {
new MyService( args, null );
}
public MyService( String args[] ) {
super( args );
...get other config params and do setup...
startService();
}
}
and I have a Jini service up and running. We need an experience like
this where all the config details and all the appropriate defaults just
happen for the user. The Seven mechanisms are similar, but the API is
richer for plugability and there is the whole deployment mechanism.
Password access:
We see occasional traffic on the list about "how do I keep joe from
using my service if it is visible on the internet?" To me, these hover
around the basic issue of how easy it is to do password based
authentication using a web interface.
I'm all for having some web interface capabilities. For me though, that would
be a serviceUI exercise. We would define the appropriate UIDescriptor that
would provide all of the details for getting a "servlet" interface to a service.
Someone would then just write a service discovery bit for throwing into apache
and it would then automatically discover and make available a web service UI to
the "world".
Proxied Authorization:
Using the Java security system is a royal pain because of the issues
with how Subject and threads of execution create context that is not
always active. So, if you instead use an instance of the service
interface as a proxy to the real service, and bury in that proxy,
all the authorization implementation, then an existing service can
have authorization pasted on top of it without the sprinkling of
java security permission checks which pretty much lock you into one
mode of authorization. I think this would be a big help to a lot of
issues revolving around overall security of network services.
> I don't expect to influence the community to make a sharp rudder change, but
> one is sorely needed to bring River from real obscurity to something of
> relevance.
I think we have to focus on the user experience and wrap a lot of the mechanics
into simple wrappers that don't remove access to the details, but just provide
reasonable defaults.
Gregg Wonderly
Re: What will eventually be in River?
Posted by Patrick Wright <pd...@gmail.com>.
Hi Gregg
I work with users, not developers, of a Jini container. I thought I'd
put in a word for what's important to us in terms of Jini service
containers. We looked at several when moving to Jini a couple of years
ago, and as I've noted before, settled on Bantam, but I think our
criteria apply regardless of our current choice.
One thing that distinguishes Bantam from other approaches is that
Bantam offers a framework for hosting services, rather than a program
which launches and starts services. That is, we can deploy a
Bantam-based service within any standard Java web container (I believe
you could use other containers to initiate the process, though). Thus
Bantam allows us to package up our services and deploy them, along
with some Bantam libraries, in a container-ized format, if one can put
it that way.
Specific questions about Bantam (or Mayflower, which provides for Jini
configuration via Spring) can go to Tom Cellucci, the project owner. I
apologize in advance if I misrepresent Bantam in any way.
- We favor using a "standard" container, such as a JEE or servlet
container, over a custom one specific to Jini, as there is usually
more documentation, testing, support for the standard containers as
such. That's not a hard-and-fast rule, but it's an advantage for us if
we can deploy services in, say, a WAR file in an unmodified servlet
container such as Tomcat. It's easier to convince our administrators
to accept a "standard" container in the production systems than (yet
another) custom one.
- We found it advantageous if the container could serve as a codebase
for its own services. There may be reasons not to do this, but having
the codebase problem--packaging and deploying JAR files--solved for us
by the Jini service framework was a real boon. Bantam can package
dependent/downloadable classes automatically on startup, and associate
the codebase URL as necessary during export. Generally this means that
if the web container goes down, so does the codebase server, which
seems about right in the simple case.
- Deploy and undeploy of services is, for us, determined by the number
of services in the WAR. We use standard WAR deploy/undeploy tools
available with the web container.
- The granularity, so to speak, of services in a deployment unit (WAR)
is up to us. We can have many service interfaces, or just one, in any
deployment unit.
- Remote deployment can be done with standard WAR deployment tools.
- Remote admin, in our case, is currently handled via JMX. Using the
support for JMX annotations in recent versions of Spring, plus
centralized JMX consoles, makes this very comfortable. We haven't
found a need for service administration above and beyond what we can
currently achieve via JMX.
- We don't have a policy for versioning (live updates to services),
though are planning on it. Unclear that we need any special support
for this from the Jini container, however, and weren't planning on
having any; rather, we'd rely on version information in the service
attributes and our custom service-lookup code on the client.
- Support for Spring-based configuration, replacing the custom Jini
config files, has been important to us, mainly because many of our
other (non-Jini) servers were already relying heavily on Spring, and
we can leverage this know-how across the team. We still use the Jini
configuration file format for our LUS and associated codebase, but not
for our own services.
- Support for auto-discovery of services by the Jini container, at
startup, has proven useful. Within the service classes, we use Java
annotations to declare the service name and some attributes of the
service. Additional configuration which is better off externalized is
handled via Spring. The Jini container locates services in the WAR
automatically at startup, prepares downloadable Jars, exports
services, etc. all based on these annotations and the associated
Spring config. For the service developer, this brings the conceptual
effort of designing a service closer to the conceptual cost of
designing the interface.
Generally speaking, on our team we have a sort of infrastructure
budget. While we spend quite a bit on infrastructure, it doesn't pay
our bills, so we have to choose carefully where to deploy those
resources. Being able to deploy into a standard container using
standard tools (e.g. 'any' servlet container with its tools) reduces
our investment in custom infrastructure. Being able to easily declare
new services for export, for example by breaking up large Java
interfaces, or merging smaller ones, is important to us.
Also, while we expect that the developers who end up writing Jini
services should know the basics of Jini, we also need them to be
problem domain experts, and anything the infrastructure can offer to
reduce the conceptual load of creating, modifying, and extending
services is a plus. Thus, the closer we can get to "just use these
annotations, make sure this is serializable, configure these two or
three beans, etc.", the more those developers can focus on what the
service needs to do, rather than how its launched, hosted, or made
available over the network. Of course we have cases where someone has
to dig deeper into the guts of Jini, but we try to avoid this unless
necessary.
To be honest, Bantam does have some gotchas, in particular related to
how JARs, classes and resources are located within the WAR file. Tom
can clarify the exact reasons, but it's not (in its current state)
without some learning curve.
Personally, I would be glad to see the various projects in this area
(service container, configuration) work on a common solution, possibly
a "low-end" solution for simple cases, and an upgrade path to
"high-end", more complex solutions. In particular, it's worthwhile to
note how much both the Spring libraries (and there are many), along
with annotations, have made some rather dreary tasks like working with
JMX and AOP very simple. JPA is another good example of, for the most
common case, simplifying what used to be a mess of configuration. I
think we in the Jini community can learn from this and apply it to the
Jini landscape. I also feel that given the low activity in many
Jini-related open source projects, it would be worth our while to pool
several projects together into a smaller number of more active
projects.
I hope this is helpful in some way, and I'm glad that you launched the
discussion.
Regards
Patrick
Re: Future of Jini/River
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thu, Nov 20, 2008 at 11:38 PM, Gregg Wonderly <ge...@cox.net> wrote:
> Over the years, there has been friction about pulling any of the
> "simplifying" bits back into the starter kit. Part of this was, of course
> because Sun owned the code and practically didn't have the means and
> mechanisms to take large contributes and integrate them I'd guess (licensing
> and work load mostly perhaps).
>
> Now that we have an open source project, the doors seem open to me.
+1
Niclas
Re: Future of Jini/River
Posted by Dan Creswell <da...@dcrdev.demon.co.uk>.
Niclas Hedhman wrote:
> On Thu, Nov 13, 2008 at 5:11 AM, Dan Creswell <da...@dcrdev.demon.co.uk> wrote:
>> And this for me has always been the crux of the matter.
>>
>> What takes Jini forward?
>
> Indeed!
>
>> Is it, dumbing it down (no offence intended to anyone)
>
> Uhhh.... Wrong attitude dude. ;-)
> If you agree that "Programming Languages are dumbing down the CPU.",
> then I can give you some acknowledgement. But in reality, they are
> empowering the programmer to do more with the CPU than ultra-clever
> little loops of 60 bytes. Jini should have the ambition to make
> distributed computing easier. It already does, but I think it can be a
> lot better...
>
>> I keep hearing how the security model get's in the way but to the best
>> of my knowledge, at least in Jini 2.x it's basically optional. The only
>> thing you require is to install a SecurityManager and have a very
>> "loose" policy file installed which is all about enabling code
>> downloading rather than catering for security.
>
> Yes, in practice this might be true, but most people I know will
> consume some documentation before jumping in, and the Security stands
> out as extremely central (which is good) and described in utter detail
> (which is bad)... IMHO, looking at this isolated from all the other
> similar experiences (RMI vs JERI, Transient/Persistent/Activation,
> Configuration) the sum is immense.
>
>> Prioritise: there's always way more to do than there is resource and
>> this is particularly true for Jini. Pick three and focus on those, and
>> if you suggest a target be prepared to back it with some effort of your
>> own.
>
> Ok. The 3 items that I am willing to back with effort;
>
> * Production of artifacts that can be consumed by other projects
> easily. This includes a Starter Kit for curious people, a Fast Track
> for common use-cases, and Development Kit with the all the gory
> details.
>
> * Support for simplified testing of Jini services and clients.
>
> * Buying beer and food for every River contributor when I visit their
> home town/city.
>
>
>> It's tempting to look at other successful projects and try and
>> copy all that one sees they've done whilst forgetting that they grew and
>> achieved all of this over a period of time, it didn't all happen
>> overnight.
>
> True, and I don't think anyone here expect changes to be complete over
> night. It is about getting the mind and process going.
>
>> Some have argued against prioritisation and singular vision in favour of
>> diversity believing it attracts a large community. I beg to differ, I
>> believe diversity comes as the result of attracting a large community
>> because you've scratched a popular itch.
>
> I agree 100% on this point. Single vision is a way to not spread the
> resources too thin.
>
>> The out-of-the box experience: IMHO, the real trouble is that Jini is a
>> network technology and networks just aren't nice, a single machine can
>> have a myriad of network interfaces, some of them with dynamic IP
>> addresses, some of them registered in DNS, some of them supporting
>> multicast etc. To address this problem requires agreeing on what a
>> minimally acceptable environment might be, having a means to determine
>> whether any given machine meets the necessary requirements and where it
>> doesn't generate useful debugging information to assist in a fix. It
>> also means deciding on what should be possible out of the box, chances
>> are the more ambitious one is, the fewer machines there will be that
>> satisfy the environmental needs by default.
>
> I disagree. The "Starter Kit" out-of-box experience does not have to
> work on all permutations of networking topology and what not. It needs
> to work on a laptop/desktop with Windows XP or later, Mac OSX and cool
> if it works on a handful of Linuxes as well, with a named JDK (1.4?)
> or later installed. I bet that covers "high nineties" of all curious
> people...
>
I think you misunderstood me - I was saying we need to agree on a
minimum standard and base our out of the box work around that. I was
not suggesting we support all arrangements, merely agree what we do
support, detect it and detect what we don't support and report/configure
accordingly....
>> I'll finish by saying that I'm pleased to see this debate. However,
>> I've seen it a number of times before and it's ultimately yielded no
>> advancement on the surface because there's been no will to compromise or
>> form consensus. Will it be any different this time?
>
> It has to be. The alternative is not an option...
>
>
> Cheers
> Niclas
>
Re: Future of Jini/River
Posted by Wade Chandler <hw...@yahoo.com>.
----- Original Message ----
> From: Wade Chandler <hw...@yahoo.com>
> To: river-dev@incubator.apache.org
> Sent: Thursday, November 13, 2008 9:02:20 AM
> Subject: Re: Future of Jini/River
>
> ----- Original Message ----
>
> > From: Niclas Hedhman
> > To: river-dev@incubator.apache.org
> > Sent: Wednesday, November 12, 2008 10:10:43 PM
> > Subject: Re: Future of Jini/River
> >
> > I disagree. The "Starter Kit" out-of-box experience does not have to
> > work on all permutations of networking topology and what not. It needs
> > to work on a laptop/desktop with Windows XP or later, Mac OSX and cool
> > if it works on a handful of Linuxes as well, with a named JDK (1.4?)
> > or later installed. I bet that covers "high nineties" of all curious
> > people...
> >
>
> I suggest 1.5. 1.6 is out and been so for a while now...update 10 is released,
> and annotations, generics, varargs, autoboxing etc all can make Jini easier to
> code. Anyways, that is my suggestion. Maybe there could be some other JAR file
> which can be included for 1.4 like other projects do now days. Personally, I
> would really love to see some kind of a profiles for Jini though. This would
> keep with the general principals on which it was based to be able to be moved
> into other devices. This would mean supporting CLDC(MIDP) and CDC, any thoughts
> here?
>
The main reason is that Jini transcends regular user or business applications, and is one of the things that really makes the technology attractive apart from it being something which can benefit many application classes. I get that folks want ease of use etc, but I suggest ease of use through API also allow complete and low level control when needed; just in case this wasn't the main idea. Annotations and other features such as new interfaces and abstract classes for starting points can make service creation much easier from a coding perspective, and then installers, setup, and configurations can be provided relatively easier for those higher level operating systems. Too, another facet is tooling for Eclipse and NetBeans at the Jini SDK level to get people going.
Thanks,
Wade
==================
Wade Chandler, CCE
Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team Member, and NetBeans Board Member
http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org
Re: Future of Jini/River
Posted by Wade Chandler <hw...@yahoo.com>.
----- Original Message ----
> From: Niclas Hedhman <ni...@hedhman.org>
> To: river-dev@incubator.apache.org
> Sent: Wednesday, November 12, 2008 10:10:43 PM
> Subject: Re: Future of Jini/River
>
> I disagree. The "Starter Kit" out-of-box experience does not have to
> work on all permutations of networking topology and what not. It needs
> to work on a laptop/desktop with Windows XP or later, Mac OSX and cool
> if it works on a handful of Linuxes as well, with a named JDK (1.4?)
> or later installed. I bet that covers "high nineties" of all curious
> people...
>
I suggest 1.5. 1.6 is out and been so for a while now...update 10 is released, and annotations, generics, varargs, autoboxing etc all can make Jini easier to code. Anyways, that is my suggestion. Maybe there could be some other JAR file which can be included for 1.4 like other projects do now days. Personally, I would really love to see some kind of a profiles for Jini though. This would keep with the general principals on which it was based to be able to be moved into other devices. This would mean supporting CLDC(MIDP) and CDC, any thoughts here?
Thanks,
Wade
Re: Future of Jini/River
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thu, Nov 13, 2008 at 5:11 AM, Dan Creswell <da...@dcrdev.demon.co.uk> wrote:
> And this for me has always been the crux of the matter.
>
> What takes Jini forward?
Indeed!
> Is it, dumbing it down (no offence intended to anyone)
Uhhh.... Wrong attitude dude. ;-)
If you agree that "Programming Languages are dumbing down the CPU.",
then I can give you some acknowledgement. But in reality, they are
empowering the programmer to do more with the CPU than ultra-clever
little loops of 60 bytes. Jini should have the ambition to make
distributed computing easier. It already does, but I think it can be a
lot better...
> I keep hearing how the security model get's in the way but to the best
> of my knowledge, at least in Jini 2.x it's basically optional. The only
> thing you require is to install a SecurityManager and have a very
> "loose" policy file installed which is all about enabling code
> downloading rather than catering for security.
Yes, in practice this might be true, but most people I know will
consume some documentation before jumping in, and the Security stands
out as extremely central (which is good) and described in utter detail
(which is bad)... IMHO, looking at this isolated from all the other
similar experiences (RMI vs JERI, Transient/Persistent/Activation,
Configuration) the sum is immense.
> Prioritise: there's always way more to do than there is resource and
> this is particularly true for Jini. Pick three and focus on those, and
> if you suggest a target be prepared to back it with some effort of your
> own.
Ok. The 3 items that I am willing to back with effort;
* Production of artifacts that can be consumed by other projects
easily. This includes a Starter Kit for curious people, a Fast Track
for common use-cases, and Development Kit with the all the gory
details.
* Support for simplified testing of Jini services and clients.
* Buying beer and food for every River contributor when I visit their
home town/city.
> It's tempting to look at other successful projects and try and
> copy all that one sees they've done whilst forgetting that they grew and
> achieved all of this over a period of time, it didn't all happen
> overnight.
True, and I don't think anyone here expect changes to be complete over
night. It is about getting the mind and process going.
> Some have argued against prioritisation and singular vision in favour of
> diversity believing it attracts a large community. I beg to differ, I
> believe diversity comes as the result of attracting a large community
> because you've scratched a popular itch.
I agree 100% on this point. Single vision is a way to not spread the
resources too thin.
> The out-of-the box experience: IMHO, the real trouble is that Jini is a
> network technology and networks just aren't nice, a single machine can
> have a myriad of network interfaces, some of them with dynamic IP
> addresses, some of them registered in DNS, some of them supporting
> multicast etc. To address this problem requires agreeing on what a
> minimally acceptable environment might be, having a means to determine
> whether any given machine meets the necessary requirements and where it
> doesn't generate useful debugging information to assist in a fix. It
> also means deciding on what should be possible out of the box, chances
> are the more ambitious one is, the fewer machines there will be that
> satisfy the environmental needs by default.
I disagree. The "Starter Kit" out-of-box experience does not have to
work on all permutations of networking topology and what not. It needs
to work on a laptop/desktop with Windows XP or later, Mac OSX and cool
if it works on a handful of Linuxes as well, with a named JDK (1.4?)
or later installed. I bet that covers "high nineties" of all curious
people...
> I'll finish by saying that I'm pleased to see this debate. However,
> I've seen it a number of times before and it's ultimately yielded no
> advancement on the surface because there's been no will to compromise or
> form consensus. Will it be any different this time?
It has to be. The alternative is not an option...
Cheers
Niclas
Re: Future of Jini/River
Posted by Jools <jo...@gmail.com>.
2008/11/14 Jeff Ramsdale <je...@gmail.com>
> On Fri, Nov 14, 2008 at 5:16 AM, Jools <jo...@gmail.com> wrote:
> <snip />
>
> > We are currently developing a maven download manager for Rio, so you can
> > deploy directly from the dependencies in a pom.xml
>
> Great news! I'd been thinking this would be a great feature but didn't
> have the bandwidth to explore it. Donating back to Rio, I hope?
>
Hi Jeff,
Too right ! We have been developing a few nice features for Rio over the
last few months and all of them will be given back to the community.
We also hope to produce some nice examples of how Rio can be used in
conjunction with other open source projects, like hibernate, restlets, jetty
etc.
Cheersm
--Jools
Re: Future of Jini/River
Posted by Jeff Ramsdale <je...@gmail.com>.
On Fri, Nov 14, 2008 at 5:16 AM, Jools <jo...@gmail.com> wrote:
<snip />
> We are currently developing a maven download manager for Rio, so you can
> deploy directly from the dependencies in a pom.xml
Great news! I'd been thinking this would be a great feature but didn't
have the bandwidth to explore it. Donating back to Rio, I hope?
-jeff
Re: Future of Jini/River
Posted by Jools <jo...@gmail.com>.
Ronald,
I totally agree with you !
The dynamic dependency download and SLA mechanisms have been a real boon for
us.
No more installing jars anymore, rio just downloads and installs them. Then
clears them away when you've finished with them !
We are currently developing a maven download manager for Rio, so you can
deploy directly from the dependencies in a pom.xml
But I digress :-)
--Jools
2008/11/14 Bowers, Ronald (Civ, ARL/SLAD) <rb...@arl.army.mil>
> On 11/12/08 6:58 PM, "Jools" <jo...@gmail.com> wrote:
>
> >>
> >> The out-of-the box experience: IMHO, the real trouble is that Jini is a
> >> network technology and networks just aren't nice, a single machine can
> >> have a myriad of network interfaces, some of them with dynamic IP
> >> addresses, some of them registered in DNS, some of them supporting
> >> multicast etc. To address this problem requires agreeing on what a
> >> minimally acceptable environment might be, having a means to determine
> >> whether any given machine meets the necessary requirements and where it
> >> doesn't generate useful debugging information to assist in a fix. It
> >> also means deciding on what should be possible out of the box, chances
> >> are the more ambitious one is, the fewer machines there will be that
> >> satisfy the environmental needs by default.
> >
> >
> > Agreed. And this is the fundamental issue with Jini, we do expose some of
> > the more difficult issues when dealing with networks, but we should be
> > looking at guiding the user through the mire.
> > I recall a project starting a while back which would probe your system
> and
> > give you some advice in regards to how best to configure jini, not sure
> > where this is now.....
> >
> > However, once the hurdles are dealt with, users of the technology become
> > instant fans.
> >
> > But the initial curve is a bit steep.
> >
> > But the benefits are worth the investment.
> >
> > My team have just deployed a Rio based system, which provides Restful
> based
> > services, dynamic load balancing and deployment all using the Rio
> toolkit.
> > Getting up to speed with Rio was a breeze for the developers as Rio
> handled
> > all the nasty stuff most developers just want to leave to the admin
> staff,
> > and the admin staff can tune the rio system for their needs.
> >
> > So, getting back to the point. Jini is not the issue, IMHO. The how easy
> we
> > make it for the user, and how confident they'll be in the end result when
> > trying to convince management that it'll work.
> >
> > --Jools
>
> Jools,
>
> I agree whole-heartedly on the joys of working with Rio rather than with
> 'naked' Jini/River. We* are developing a distributed simulation
> environment.
> We stared it in Jini, but quickly ran into issues. First, as you said the
> learning curve was steep. That made it difficult to get other team members
> to be able to help with service development. Other issues were
>
> - How do I deploy my services to the dozens or hundreds of available
> machines?
> - Given a heterogeneous computing environment, how can I ensure that
> services are deployed only to machines capable of handling them, and
> - A whole lot of boilerplate code to establish relationships between
> services.
>
> Anyway, now that we are using Rio, we spend much more of our time working
> at
> the application level rather than at the service communication level. In
> turn, this has enabled us to take a project that was near death and start
> making it successful. I am also very pleased to say that we have been able
> to contribute back to the community by funding several enhancements to
> Rio.**
>
> -Ron
>
>
> * The U.S. Army Research Laboratory
> ** shameless plug :)
>
>
Re: Future of Jini/River
Posted by Dan Creswell <da...@dcrdev.demon.co.uk>.
I actually wrote a utility to help with this sort of thing recently (not
for Jini) and it's somewhat easier than it used to be with a later JDK -
so it might've been a tough job previously but should be relatively
doable now. Might even make a good starter project for someone....
Jools wrote:
>> The out-of-the box experience: IMHO, the real trouble is that Jini is a
>> network technology and networks just aren't nice, a single machine can
>> have a myriad of network interfaces, some of them with dynamic IP
>> addresses, some of them registered in DNS, some of them supporting
>> multicast etc. To address this problem requires agreeing on what a
>> minimally acceptable environment might be, having a means to determine
>> whether any given machine meets the necessary requirements and where it
>> doesn't generate useful debugging information to assist in a fix. It
>> also means deciding on what should be possible out of the box, chances
>> are the more ambitious one is, the fewer machines there will be that
>> satisfy the environmental needs by default.
>
>
> Agreed. And this is the fundamental issue with Jini, we do expose some of
> the more difficult issues when dealing with networks, but we should be
> looking at guiding the user through the mire.
> I recall a project starting a while back which would probe your system and
> give you some advice in regards to how best to configure jini, not sure
> where this is now.....
>
> However, once the hurdles are dealt with, users of the technology become
> instant fans.
>
> But the initial curve is a bit steep.
>
> But the benefits are worth the investment.
>
> My team have just deployed a Rio based system, which provides Restful based
> services, dynamic load balancing and deployment all using the Rio toolkit.
> Getting up to speed with Rio was a breeze for the developers as Rio handled
> all the nasty stuff most developers just want to leave to the admin staff,
> and the admin staff can tune the rio system for their needs.
>
> So, getting back to the point. Jini is not the issue, IMHO. The how easy we
> make it for the user, and how confident they'll be in the end result when
> trying to convince management that it'll work.
>
> --Jools
>
What will eventually be in River?
Posted by Gregg Wonderly <ge...@cox.net>.
The recent question about containers and the numerous responses indicate that
there are many different people and projects who have been interested in a
container mechanism for Jini service deployment and management. I'd like to
start a list of container features discussion.
What I am interested in, is seeing if there are a set of foundational
capabilities which all of these different container systems have/provide and if
there is a way that perhaps the totality of all such features might be
integrated into a "container" for River in the not too distant future.
I really feel that deployment control and management of the system overall is an
important part of how Jini will succeed overall.
Would the authors of the various containers be interested in providing a list of
features that they feel their containers provide?
I'll start the process by providing a list of things that I think containers are
known to provide at a high level. Lower level details such as how those things
are provided might be interesting to discuss as well.
What I consider to be the core functionality of a container is the following set
of capabilities.
1. Remote deployment control. Can you attach to a VM and start a new
service/instance remotely?
2. Remote configuration management. Can you ship a new configuration and
restart a service with that configuration remotely?
3. Versioning in deployment mechanisms to allow old services to be unloaded
and upgraded instances started without a restart of the VM.
The following are things which might help with use in a particular environment.
These are things which I have heard others mention here that are either
interesting or required attributes for their needs.
4. Support for integration into a J2EE server (I understand that apache has
the needed support for security manager and class loader selection to
make this possible, while others perhaps still don't?).
5. Spring based deployment/configuration. I.e. is spring used as a primary
mechanism in your containers APIs/implementation.
I'm interested in responses to the completeness of this list of things that
might be the "core" of a good Jini container. There are of course a whole slew
of things that are what I consider implementation details that could be required
attributes. These are things like how APIs for container use impact existing
software modules, interface vs abstract class issues etc. I'm not as interested
in low level details for this discussion, but I'd like to hear what people think
is valuable to them.
Gregg Wonderly
Re: Future of Jini/River
Posted by Gregg Wonderly <ge...@cox.net>.
Jools wrote:
>> The out-of-the box experience: IMHO, the real trouble is that Jini is a
>> network technology and networks just aren't nice, a single machine can
>> have a myriad of network interfaces, some of them with dynamic IP
>> addresses, some of them registered in DNS, some of them supporting
>> multicast etc. To address this problem requires agreeing on what a
>> minimally acceptable environment might be, having a means to determine
>> whether any given machine meets the necessary requirements and where it
>> doesn't generate useful debugging information to assist in a fix. It
>> also means deciding on what should be possible out of the box, chances
>> are the more ambitious one is, the fewer machines there will be that
>> satisfy the environmental needs by default.
>
> Agreed. And this is the fundamental issue with Jini, we do expose some of
> the more difficult issues when dealing with networks, but we should be
> looking at guiding the user through the mire.
This is one of the things that RIO and other Jini projects have done, over time.
They've derived the foundation of Jini into more useful toolsets focused on
solving some types of problems easier.
Over the years, there has been friction about pulling any of the "simplifying"
bits back into the starter kit. Part of this was, of course because Sun owned
the code and practically didn't have the means and mechanisms to take large
contributes and integrate them I'd guess (licensing and work load mostly perhaps).
Now that we have an open source project, the doors seem open to me.
Gregg Wonderly
Re: Future of Jini/River
Posted by "Bowers, Ronald (Civ, ARL/SLAD)" <rb...@arl.army.mil>.
On 11/12/08 6:58 PM, "Jools" <jo...@gmail.com> wrote:
>>
>> The out-of-the box experience: IMHO, the real trouble is that Jini is a
>> network technology and networks just aren't nice, a single machine can
>> have a myriad of network interfaces, some of them with dynamic IP
>> addresses, some of them registered in DNS, some of them supporting
>> multicast etc. To address this problem requires agreeing on what a
>> minimally acceptable environment might be, having a means to determine
>> whether any given machine meets the necessary requirements and where it
>> doesn't generate useful debugging information to assist in a fix. It
>> also means deciding on what should be possible out of the box, chances
>> are the more ambitious one is, the fewer machines there will be that
>> satisfy the environmental needs by default.
>
>
> Agreed. And this is the fundamental issue with Jini, we do expose some of
> the more difficult issues when dealing with networks, but we should be
> looking at guiding the user through the mire.
> I recall a project starting a while back which would probe your system and
> give you some advice in regards to how best to configure jini, not sure
> where this is now.....
>
> However, once the hurdles are dealt with, users of the technology become
> instant fans.
>
> But the initial curve is a bit steep.
>
> But the benefits are worth the investment.
>
> My team have just deployed a Rio based system, which provides Restful based
> services, dynamic load balancing and deployment all using the Rio toolkit.
> Getting up to speed with Rio was a breeze for the developers as Rio handled
> all the nasty stuff most developers just want to leave to the admin staff,
> and the admin staff can tune the rio system for their needs.
>
> So, getting back to the point. Jini is not the issue, IMHO. The how easy we
> make it for the user, and how confident they'll be in the end result when
> trying to convince management that it'll work.
>
> --Jools
Jools,
I agree whole-heartedly on the joys of working with Rio rather than with
'naked' Jini/River. We* are developing a distributed simulation environment.
We stared it in Jini, but quickly ran into issues. First, as you said the
learning curve was steep. That made it difficult to get other team members
to be able to help with service development. Other issues were
- How do I deploy my services to the dozens or hundreds of available
machines?
- Given a heterogeneous computing environment, how can I ensure that
services are deployed only to machines capable of handling them, and
- A whole lot of boilerplate code to establish relationships between
services.
Anyway, now that we are using Rio, we spend much more of our time working at
the application level rather than at the service communication level. In
turn, this has enabled us to take a project that was near death and start
making it successful. I am also very pleased to say that we have been able
to contribute back to the community by funding several enhancements to
Rio.**
-Ron
* The U.S. Army Research Laboratory
** shameless plug :)
Re: Future of Jini/River
Posted by Jools <jo...@gmail.com>.
>
> The out-of-the box experience: IMHO, the real trouble is that Jini is a
> network technology and networks just aren't nice, a single machine can
> have a myriad of network interfaces, some of them with dynamic IP
> addresses, some of them registered in DNS, some of them supporting
> multicast etc. To address this problem requires agreeing on what a
> minimally acceptable environment might be, having a means to determine
> whether any given machine meets the necessary requirements and where it
> doesn't generate useful debugging information to assist in a fix. It
> also means deciding on what should be possible out of the box, chances
> are the more ambitious one is, the fewer machines there will be that
> satisfy the environmental needs by default.
Agreed. And this is the fundamental issue with Jini, we do expose some of
the more difficult issues when dealing with networks, but we should be
looking at guiding the user through the mire.
I recall a project starting a while back which would probe your system and
give you some advice in regards to how best to configure jini, not sure
where this is now.....
However, once the hurdles are dealt with, users of the technology become
instant fans.
But the initial curve is a bit steep.
But the benefits are worth the investment.
My team have just deployed a Rio based system, which provides Restful based
services, dynamic load balancing and deployment all using the Rio toolkit.
Getting up to speed with Rio was a breeze for the developers as Rio handled
all the nasty stuff most developers just want to leave to the admin staff,
and the admin staff can tune the rio system for their needs.
So, getting back to the point. Jini is not the issue, IMHO. The how easy we
make it for the user, and how confident they'll be in the end result when
trying to convince management that it'll work.
--Jools
Re: Future of Jini/River
Posted by Dan Creswell <da...@dcrdev.demon.co.uk>.
And this for me has always been the crux of the matter.
What takes Jini forward?
Is it, dumbing it down (no offence intended to anyone), is it to fix
some bugs, is it to add some new features, is it to have some kind of
target problemspace that is smaller than all and sundry?
All the code in the world is useless without tackling this core question
which comes down to agreeing a vision/direction. As an aside, I've often
thought that the real "power" of Jini is the underlying design
philosophy rather than the code, certainly I've applied it elsewhere
successfully without needing dynamic code downloading or security or
even Java.
Some random thoughts:
I keep hearing how the security model get's in the way but to the best
of my knowledge, at least in Jini 2.x it's basically optional. The only
thing you require is to install a SecurityManager and have a very
"loose" policy file installed which is all about enabling code
downloading rather than catering for security.
Jini, because of it's design philosophy is quite different from most
other systems. It looks a little like OSGi and they are somewhat
compatible, probably complementary. Inevitably this brings tension when
trying to make Jini fit with other approaches. It can be done, but
there's a compromise, I reckon it's about time we explicitly discussed
what compromises might be possible and what the penalties are.
Prioritise: there's always way more to do than there is resource and
this is particularly true for Jini. Pick three and focus on those, and
if you suggest a target be prepared to back it with some effort of your
own. It's tempting to look at other successful projects and try and
copy all that one sees they've done whilst forgetting that they grew and
achieved all of this over a period of time, it didn't all happen
overnight. I would argue that even this:
"Let's make the code easy to get, easy to build, easy to
use. Let's post nightly builds. Let's add something to the roadmap
(like maybe a release schedule? And then plan on regular releases...).
Let's ask each of the service container providers (Rio, Seven, etc.)
and the community what their top 3 feature requests are and find the
low-hanging fruit (InputStreams!)."
....is too much to start with. Three things, only three things, don't
get ambitious, crawl, then walk, then run.
Some have argued against prioritisation and singular vision in favour of
diversity believing it attracts a large community. I beg to differ, I
believe diversity comes as the result of attracting a large community
because you've scratched a popular itch.
The out-of-the box experience: IMHO, the real trouble is that Jini is a
network technology and networks just aren't nice, a single machine can
have a myriad of network interfaces, some of them with dynamic IP
addresses, some of them registered in DNS, some of them supporting
multicast etc. To address this problem requires agreeing on what a
minimally acceptable environment might be, having a means to determine
whether any given machine meets the necessary requirements and where it
doesn't generate useful debugging information to assist in a fix. It
also means deciding on what should be possible out of the box, chances
are the more ambitious one is, the fewer machines there will be that
satisfy the environmental needs by default.
I'll finish by saying that I'm pleased to see this debate. However,
I've seen it a number of times before and it's ultimately yielded no
advancement on the surface because there's been no will to compromise or
form consensus. Will it be any different this time?
Cheers,
Dan.
Sam Chance wrote:
> Gregg,
>
> Please forgive me for what I'm about to say. While all this is surely an
> engineering marvel - and perhaps necessary, it has no impact or wow factor
> to motivate 'outsiders' to download, install and use it.
>
> I don't expect to influence the community to make a sharp rudder change, but
> one is sorely needed to bring River from real obscurity to something of
> relevance.
>
> Sam
>
> On Mon, Nov 10, 2008 at 3:04 PM, Gregg Wonderly <gr...@wonderly.org> wrote:
>
>> I'd still like to promote a new lookup server that includes my changes to
>> provide the unmarshalled objects as the result of lookup. This would imply
>> that marshaling of service objects would be a documented behavior of such a
>> lookup service. The benefits are delayed code downloading as well as the
>> ability to pass a services/objects between services without the "lost
>> codebase" problem.
>>
>> I'd still like to promote a much richer set of APIs for GUI based service
>> UI and contribute my Jini desktop environment into River as an example of
>> how to use Jini for distributing desktop applications to users with the
>> dynamic update capabilities associated with mobile code.
>>
>> I'd still like to get a password based authentication system into the
>> distribution by default. It could use a service provider mechanism for
>> getting to authentication stores. I have a PAM based JNI provider for
>> linux. Certs work now, but are not always the right answer, and are one of
>> those huge barries for anyone who just wants to control who can use a
>> service. I think this is the number one barrier to small service
>> proliferation from new developers. They create web pages all the time with
>> password authentication easy enough. But they take Jini as a network
>> service and can't do it easily at all.
>>
>> I'd still like to make it so that inbound calls run as the remote user's
>> Subject, not as the local service Subject with access to the remote
>> Principals as a secondary step.
>>
>> I'd still like to provide my proxied authorization system to the community.
>> This system uses an XML spec to generate a proxy delegating implementation
>> of the service interfaces. It uses a provided backing store for persistence
>> of the authorization. Authentication is through a service provider
>> mechanism. It provides a service ui to manage the authorization
>> configuration. This allows you to plug in authorization support at the
>> service export location. A custom exporter could even do this for you.
>>
>> Right now, I pretty much have my own fork of Jini for the lookup support.
>> All these other things are separate libraries which I use to put together
>> the applications that I need. I'd like to get back to the point of using
>> the River codebase and helping with it's evolution (or revolution as the
>> case may be). The lookup server changes I made are just a simple adaptation
>> to the implementation of reggie. It does provide the ability to not allow
>> access to the unmarshalled data through the use of an interface which is
>> optionally on the Reggie service object.
>>
>> In my cases, I need to have zero code downloads at startup. The networks
>> are very high latency. I do have to undergo the HTTP HEAD operation to
>> check for jars that are out of date in the use of my vhttp: protocol
>> handler. So, one round trip does happen, per jar file, but only if that jar
>> file is referenced.
>> Through changes to PreferredClassProvider and ClassLoading, I can designate
>> classes as never preferred so that their resolution will not result in class
>> loading. This allows me to designate classes such as Name, ServiceType and
>> others as never preferred and thus I can take all the discovery results and
>> render an entire desktop of names and icons without any network traffic.
>>
>> This type of "detail" and "optimization", for me, is a barrier to entry.
>> People who don't understand the details, will still find value is such
>> optimizations, but not really understand how or where the effect them.
>>
>> Gregg Wonderly
>>
>
Re: Future of Jini/River
Posted by Sam Chance <sg...@gmail.com>.
Gregg,
Please forgive me for what I'm about to say. While all this is surely an
engineering marvel - and perhaps necessary, it has no impact or wow factor
to motivate 'outsiders' to download, install and use it.
I don't expect to influence the community to make a sharp rudder change, but
one is sorely needed to bring River from real obscurity to something of
relevance.
Sam
On Mon, Nov 10, 2008 at 3:04 PM, Gregg Wonderly <gr...@wonderly.org> wrote:
> I'd still like to promote a new lookup server that includes my changes to
> provide the unmarshalled objects as the result of lookup. This would imply
> that marshaling of service objects would be a documented behavior of such a
> lookup service. The benefits are delayed code downloading as well as the
> ability to pass a services/objects between services without the "lost
> codebase" problem.
>
> I'd still like to promote a much richer set of APIs for GUI based service
> UI and contribute my Jini desktop environment into River as an example of
> how to use Jini for distributing desktop applications to users with the
> dynamic update capabilities associated with mobile code.
>
> I'd still like to get a password based authentication system into the
> distribution by default. It could use a service provider mechanism for
> getting to authentication stores. I have a PAM based JNI provider for
> linux. Certs work now, but are not always the right answer, and are one of
> those huge barries for anyone who just wants to control who can use a
> service. I think this is the number one barrier to small service
> proliferation from new developers. They create web pages all the time with
> password authentication easy enough. But they take Jini as a network
> service and can't do it easily at all.
>
> I'd still like to make it so that inbound calls run as the remote user's
> Subject, not as the local service Subject with access to the remote
> Principals as a secondary step.
>
> I'd still like to provide my proxied authorization system to the community.
> This system uses an XML spec to generate a proxy delegating implementation
> of the service interfaces. It uses a provided backing store for persistence
> of the authorization. Authentication is through a service provider
> mechanism. It provides a service ui to manage the authorization
> configuration. This allows you to plug in authorization support at the
> service export location. A custom exporter could even do this for you.
>
> Right now, I pretty much have my own fork of Jini for the lookup support.
> All these other things are separate libraries which I use to put together
> the applications that I need. I'd like to get back to the point of using
> the River codebase and helping with it's evolution (or revolution as the
> case may be). The lookup server changes I made are just a simple adaptation
> to the implementation of reggie. It does provide the ability to not allow
> access to the unmarshalled data through the use of an interface which is
> optionally on the Reggie service object.
>
> In my cases, I need to have zero code downloads at startup. The networks
> are very high latency. I do have to undergo the HTTP HEAD operation to
> check for jars that are out of date in the use of my vhttp: protocol
> handler. So, one round trip does happen, per jar file, but only if that jar
> file is referenced.
> Through changes to PreferredClassProvider and ClassLoading, I can designate
> classes as never preferred so that their resolution will not result in class
> loading. This allows me to designate classes such as Name, ServiceType and
> others as never preferred and thus I can take all the discovery results and
> render an entire desktop of names and icons without any network traffic.
>
> This type of "detail" and "optimization", for me, is a barrier to entry.
> People who don't understand the details, will still find value is such
> optimizations, but not really understand how or where the effect them.
>
> Gregg Wonderly
>
Re: Future of Jini/River
Posted by Gregg Wonderly <gr...@wonderly.org>.
I'd still like to promote a new lookup server that includes my changes to
provide the unmarshalled objects as the result of lookup. This would imply that
marshaling of service objects would be a documented behavior of such a lookup
service. The benefits are delayed code downloading as well as the ability to
pass a services/objects between services without the "lost codebase" problem.
I'd still like to promote a much richer set of APIs for GUI based service UI and
contribute my Jini desktop environment into River as an example of how to use
Jini for distributing desktop applications to users with the dynamic update
capabilities associated with mobile code.
I'd still like to get a password based authentication system into the
distribution by default. It could use a service provider mechanism for getting
to authentication stores. I have a PAM based JNI provider for linux. Certs
work now, but are not always the right answer, and are one of those huge barries
for anyone who just wants to control who can use a service. I think this is the
number one barrier to small service proliferation from new developers. They
create web pages all the time with password authentication easy enough. But
they take Jini as a network service and can't do it easily at all.
I'd still like to make it so that inbound calls run as the remote user's
Subject, not as the local service Subject with access to the remote Principals
as a secondary step.
I'd still like to provide my proxied authorization system to the community.
This system uses an XML spec to generate a proxy delegating implementation of
the service interfaces. It uses a provided backing store for persistence of the
authorization. Authentication is through a service provider mechanism. It
provides a service ui to manage the authorization configuration. This allows
you to plug in authorization support at the service export location. A custom
exporter could even do this for you.
Right now, I pretty much have my own fork of Jini for the lookup support. All
these other things are separate libraries which I use to put together the
applications that I need. I'd like to get back to the point of using the River
codebase and helping with it's evolution (or revolution as the case may be).
The lookup server changes I made are just a simple adaptation to the
implementation of reggie. It does provide the ability to not allow access to
the unmarshalled data through the use of an interface which is optionally on the
Reggie service object.
In my cases, I need to have zero code downloads at startup. The networks are
very high latency. I do have to undergo the HTTP HEAD operation to check for
jars that are out of date in the use of my vhttp: protocol handler. So, one
round trip does happen, per jar file, but only if that jar file is referenced.
Through changes to PreferredClassProvider and ClassLoading, I can designate
classes as never preferred so that their resolution will not result in class
loading. This allows me to designate classes such as Name, ServiceType and
others as never preferred and thus I can take all the discovery results and
render an entire desktop of names and icons without any network traffic.
This type of "detail" and "optimization", for me, is a barrier to entry. People
who don't understand the details, will still find value is such optimizations,
but not really understand how or where the effect them.
Gregg Wonderly
Re: Future of Jini/River
Posted by Jeff Ramsdale <je...@gmail.com>.
Hey Jeremy,
Just wanted to mention that the main page at Jini.org is a template
page that pulls in content from other pages dynamically (view the
source for details). While it's true the page itself hasn't changed
since January the content on that page does periodically change. Would
be delighted if more submissions came in, of course...
-jeff
On Mon, Nov 10, 2008 at 6:50 AM, Jeremy Easton-Marks
<co...@gmail.com> wrote:
> As a potential new user to Jini/River I wanted to share my first impressions
> of this project.
>
> River has great potential, it seems like the solution to many common
> distributed computing problems. I am excited to potentially be using it in
> my next project. I have been a fan of Jini/River since I first learned about
> in 1999. I am glad that Jini did not die and was picked up by a community
> that is full of professionals who are genuinely interested in moving this
> project forward.
>
> All that being said I am nervous about a few things. The biggest being the
> lack of a good tutorial, and documentation. I noticed on the old site,
> jini.org, that there were some basic tutorials and documentation. I am not
> sure if those tutorials and documentation will work with the newest
> iteration. The last update on the front page is from January 2008. This at
> first appearance seems like Apache River is a dying project.
>
> I believe Niclas hit the perverbial nail on the head when he said " We need
> to make River more accessible for non-hardcore Jini users." I am not a
> hardcore Jini user but would like to learn more about it, use it and then
> possibly become a "hardcore" user.
>
> The only thing I would to add to Nicolas's email is that if the Jini/River
> community needs to publish and promote. If nobody knows about Jini/River
> then nobody is going to use it. Other developers need to see how Jini/River
> can benefit them and make their lives easier.
>
> I think it is also important to point that while a conversation is great, it
> is more important to have actions. On that note I would like to become more
> involved in this project and help out in any way possible. So anyone please
> point me in the right direction to get started.
>
> Jeremy R. Easton-Marks
>
> "être fort pour être utile"
Re: Future of Jini/River
Posted by Jeremy Easton-Marks <co...@gmail.com>.
As a potential new user to Jini/River I wanted to share my first impressions
of this project.
River has great potential, it seems like the solution to many common
distributed computing problems. I am excited to potentially be using it in
my next project. I have been a fan of Jini/River since I first learned about
in 1999. I am glad that Jini did not die and was picked up by a community
that is full of professionals who are genuinely interested in moving this
project forward.
All that being said I am nervous about a few things. The biggest being the
lack of a good tutorial, and documentation. I noticed on the old site,
jini.org, that there were some basic tutorials and documentation. I am not
sure if those tutorials and documentation will work with the newest
iteration. The last update on the front page is from January 2008. This at
first appearance seems like Apache River is a dying project.
I believe Niclas hit the perverbial nail on the head when he said " We need
to make River more accessible for non-hardcore Jini users." I am not a
hardcore Jini user but would like to learn more about it, use it and then
possibly become a "hardcore" user.
The only thing I would to add to Nicolas's email is that if the Jini/River
community needs to publish and promote. If nobody knows about Jini/River
then nobody is going to use it. Other developers need to see how Jini/River
can benefit them and make their lives easier.
I think it is also important to point that while a conversation is great, it
is more important to have actions. On that note I would like to become more
involved in this project and help out in any way possible. So anyone please
point me in the right direction to get started.
Jeremy R. Easton-Marks
"être fort pour être utile"
On Sun, Nov 9, 2008 at 10:50 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> Taking this on-list, which I perhaps should have done in the first
> place. Never-the-less,
>
> On Mon, Nov 10, 2008 at 12:17 AM, Dan Creswell <da...@dcrdev.demon.co.uk>
> wrote:
>
> > For a long time now, I've been waiting to see a conversation around
> > "what next for River". This is something of a good start but....
>
> People don't like to work alone and 'against all odds', so I think all
> of River's problems are related to a couple of real problems;
>
> * It is perhaps too complete! Not that many things that is in
> desperate need of repairs.
>
> * Overload of Information and Technology Fracture. We have a million
> documents, a couple of sites, dozens of related projects that are
> spread out and for a newcomer it is unclear what is essential, useful
> vs not initially relevant. It is in fact the total opposite of most
> projects at Apache.
>
> * Corporate Approach to software distribution. You get something that
> you install and use, pretty much like a big fat database, application
> server or similar. Modern developers, often test driven and agile, are
> not fond of "System Requirements" when writing their own software.
> "Check out, compile, run tests" is the motto for many, me included.
> For Jini, it means it is hard to create other open source projects
> that depends on Jini. The downstream users have to do too much to get
> going. This is probably my pet peeve at the moment.
>
> These things are not very concrete. We need to make River more
> accessible for non-hardcore Jini users. It must be easy to "see the
> light" (samples), "to touch the light" (try yourself) and "follow the
> light" (embrace) at a very fundamental level. Jini applications
> doesn't live in a vaccuum, the technology must be easier to integrate
> into other projects. The hardline view that "we are best and everyone
> else should learn from us" ain't gonna cut it.
>
> My own view is that the following areas are first up for review and
> rectification;
>
> * Build System. It must be a breeze to build and test River itself.
> The current split between tests and source code should IMHO be
> eliminated, tests should be executed on all builds, and I think we
> should break up the sources into modules instead of a single large
> src/ dir with everything in it. If people wants to move towards Maven,
> I will support that, primarily since it simplifies artifact
> consumption for downstream projects. Same thing can however be
> achieved with Ant.
>
> * Right-sizing of the Jini Starter Kit. IMHO, the JSK is a misnomer
> unless you intend to write your own Jini implementation of the
> Specification services. I think that Apache River could just organize
> the whole project better, to get around this problem altogether. I
> think we can see a "infrastructure product" separate from the
> "developer's tools".
>
> * Configuration System. Although I like it in principle (after all I
> was in the JSR-78 EG where it came to light in the first place), BUT
> it needs better adjustment to agile and TDD methodologies. Perhaps it
> is only a documentation issue, but I have been faced with using
> filesystem files to get things going. InputStreams are the way to go.
>
> * Security System. Although extremely important in many scenarios, the
> impact on developers for Jini is too big, too soon. Needs to soften
> that up in the documentation, which currently deals with experts and
> novices alike.
>
> * RMI & JERI, Activatable, Persisten or Transient... Duhhh... Give me
> choices that I initially don't care about, and I give you a system
> that is booted out from the candidate list. The information around
> what each means is overwhelming. I would say that RMI has such
> (undeserved IMHO) bad reputation that drop it out of the mainstream,
> push JERI as "The Java Binary Communication Layer", and IIRC it is
> well suited to have other serialization protocols than std Object
> Serialization Streams, which would allow people to experiment, measure
> and conclude the true story around serialization (what ever that might
> be). So, big tasks in place to make JERI more easily consumable.
>
> * River/Jini 3.0. I think a healthy community needs lofty goals. At
> ApacheCon Europe 2008, Roy Fielding was talking about this for Apache
> Web Server. He basically called for "next level" of what is possible,
> put up serious ambitions and 'screw compatibility' to get there. I
> think River could start flowing if some discussion is created along,
> "What's the Next Thing?" and see where that leads us. I can imagine
> Clouds, Distributed Storage, Network Graph Navigation/Search, new
> "Distributed Worker Model", maybe even standard solutions for load
> balancing http traffic. Well, I am sure there is a lot to discuss and
> dream about. From those dreams come itches, the itches get scratched,
> and so on...
>
>
> All in all, I love Jini, but I think the current situation stinks and
> if we (those who care) don't do something really soon, it will be a
> blip on the radar of Java history. I can unfortunately NOT be the
> driving force behind the technology. First, I lack the know-how
> required, and secondly I am tied up in a really large open source
> project (http://www.qi4j.org), but where I hope to use Jini/River as a
> distribution platform. So I could help out in various areas, just to
> make my own situation more bearable (scratch the itch).
>
>
> Cheers
> Niclas
>
Re: Future of Jini/River
Posted by Sam Chance <sg...@gmail.com>.
All,
I'm typically a lurker, just watching to see what deployment/operational
issues emerge that inspire healthy discussion on the list. However, I
occasionally pop in and offer my humble opinion.
There are a few topics I'll add into the mix that I think could make
Jini/River gain some prominence. These might include a visual,
browser-based lifecycle service management, explicit use of OSGi technology,
and/or the seemingly allusive killer app.
Firstly, I'll mention a couple of dynamics that I believe continue to hold
Jini down. As a point of fact, when I mention Jini, it's always in the past
tense. For example, I might say to someone, 'Do you recall Jini?' or 'Have
you ever heard of Jini?' Usually they acknowledge in a 'weak affirmative';
however, they may or may not actually know to what I'm referring. One
really sad fact is that no one who has been part of the community will jump
up and down screaming that we need to do something. It seems every time the
"future of Jini" topic is raised the 'community' simply defends the status
quo. It's almost like a self-licking ice cream cone, and the folks who make
the ice cream are happy to eat the ice cream. Accordingly, the
(exceptional) technology remains stagnated in mediocrity and relative
obscurity.
We can't even seem to get Jini/River adopted as a SOA framework. I've seen
no efforts to create and market a River-based BPM/Orchestration capability.
Is there any Web 2.0 type application? What about Web 3.0 and linked data?
Better yet, what about "linked services"? What about dynamic service
"publish, find and bind" (PF&B) over the intranet or even internet?
We had a visual Jini IDE called IncaX that was, I thought, an awesome
capability that never really got hardened and adopted by the community, much
less the outside world.
I struggle to fathom there remains no browser-based (AJAX) management
framework! If there is one, please excuse me and show me the link. In
today's world, it's a minimal requirement. That's something the whole
community could rally around.
We had (have?) Seven. We have, I think, RIO. GigsSpaces? Infiniflow?
Those are either exeedingly obscure in the mainstream or are COTS.
If any of you, who are much smarter than me, have looked at OSGi technology,
one of the first things that SHOULD scream at you is the exceeding symmetry
between Jini and the OSGi service platform. To my knowledge, only Paremus
has the vision to leverage that symmetry. And guess what? I'm doing all I
can to help their cause!
We have Bantam which is another creative use that facilitates dynamic PF&B
over HTTP. But of those who know about it who is helping build it out? Who
is helping market it?
We say Jini is protocol agnostic, but to my knowledge, only RMI is
implemented. We need other bindings, like an ATOM binding. How "Web
2.0'ish"! What about REST? SOAP?
At the end of the day, all these would probably work, but the community
seems content to remain "within itself". It fails to coalesce around any
particular vision.
So I offer a vision: Using River, build an internet scale, decentralized,
autonomic, dynamic PF&B service management APPLICATION that is browser base,
OSGi technology based and Service Component Architecture (SCA) based. The
framework should allow rapid creation and deployment of services. The
binding protocol should be based on ATOM or something similarly open. It
shoud allow end users to build ad hoc worklfow by combining services. It
should not be wed to SOAP, but allow SOAP. It should allow REST also.
That is a River that allows all manner of things to flow through it! :-)
Thank you!
Sam
On Sun, Nov 9, 2008 at 11:50 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> Taking this on-list, which I perhaps should have done in the first
> place. Never-the-less,
>
> On Mon, Nov 10, 2008 at 12:17 AM, Dan Creswell <da...@dcrdev.demon.co.uk>
> wrote:
>
> > For a long time now, I've been waiting to see a conversation around
> > "what next for River". This is something of a good start but....
>
> People don't like to work alone and 'against all odds', so I think all
> of River's problems are related to a couple of real problems;
>
> * It is perhaps too complete! Not that many things that is in
> desperate need of repairs.
>
> * Overload of Information and Technology Fracture. We have a million
> documents, a couple of sites, dozens of related projects that are
> spread out and for a newcomer it is unclear what is essential, useful
> vs not initially relevant. It is in fact the total opposite of most
> projects at Apache.
>
> * Corporate Approach to software distribution. You get something that
> you install and use, pretty much like a big fat database, application
> server or similar. Modern developers, often test driven and agile, are
> not fond of "System Requirements" when writing their own software.
> "Check out, compile, run tests" is the motto for many, me included.
> For Jini, it means it is hard to create other open source projects
> that depends on Jini. The downstream users have to do too much to get
> going. This is probably my pet peeve at the moment.
>
> These things are not very concrete. We need to make River more
> accessible for non-hardcore Jini users. It must be easy to "see the
> light" (samples), "to touch the light" (try yourself) and "follow the
> light" (embrace) at a very fundamental level. Jini applications
> doesn't live in a vaccuum, the technology must be easier to integrate
> into other projects. The hardline view that "we are best and everyone
> else should learn from us" ain't gonna cut it.
>
> My own view is that the following areas are first up for review and
> rectification;
>
> * Build System. It must be a breeze to build and test River itself.
> The current split between tests and source code should IMHO be
> eliminated, tests should be executed on all builds, and I think we
> should break up the sources into modules instead of a single large
> src/ dir with everything in it. If people wants to move towards Maven,
> I will support that, primarily since it simplifies artifact
> consumption for downstream projects. Same thing can however be
> achieved with Ant.
>
> * Right-sizing of the Jini Starter Kit. IMHO, the JSK is a misnomer
> unless you intend to write your own Jini implementation of the
> Specification services. I think that Apache River could just organize
> the whole project better, to get around this problem altogether. I
> think we can see a "infrastructure product" separate from the
> "developer's tools".
>
> * Configuration System. Although I like it in principle (after all I
> was in the JSR-78 EG where it came to light in the first place), BUT
> it needs better adjustment to agile and TDD methodologies. Perhaps it
> is only a documentation issue, but I have been faced with using
> filesystem files to get things going. InputStreams are the way to go.
>
> * Security System. Although extremely important in many scenarios, the
> impact on developers for Jini is too big, too soon. Needs to soften
> that up in the documentation, which currently deals with experts and
> novices alike.
>
> * RMI & JERI, Activatable, Persisten or Transient... Duhhh... Give me
> choices that I initially don't care about, and I give you a system
> that is booted out from the candidate list. The information around
> what each means is overwhelming. I would say that RMI has such
> (undeserved IMHO) bad reputation that drop it out of the mainstream,
> push JERI as "The Java Binary Communication Layer", and IIRC it is
> well suited to have other serialization protocols than std Object
> Serialization Streams, which would allow people to experiment, measure
> and conclude the true story around serialization (what ever that might
> be). So, big tasks in place to make JERI more easily consumable.
>
> * River/Jini 3.0. I think a healthy community needs lofty goals. At
> ApacheCon Europe 2008, Roy Fielding was talking about this for Apache
> Web Server. He basically called for "next level" of what is possible,
> put up serious ambitions and 'screw compatibility' to get there. I
> think River could start flowing if some discussion is created along,
> "What's the Next Thing?" and see where that leads us. I can imagine
> Clouds, Distributed Storage, Network Graph Navigation/Search, new
> "Distributed Worker Model", maybe even standard solutions for load
> balancing http traffic. Well, I am sure there is a lot to discuss and
> dream about. From those dreams come itches, the itches get scratched,
> and so on...
>
>
> All in all, I love Jini, but I think the current situation stinks and
> if we (those who care) don't do something really soon, it will be a
> blip on the radar of Java history. I can unfortunately NOT be the
> driving force behind the technology. First, I lack the know-how
> required, and secondly I am tied up in a really large open source
> project (http://www.qi4j.org), but where I hope to use Jini/River as a
> distribution platform. So I could help out in various areas, just to
> make my own situation more bearable (scratch the itch).
>
>
> Cheers
> Niclas
>
--
Sam Chance
443-694-5293 (m)
410-694-0240 x108 (o)