On 2/12/2011 7:10 AM, Niclas Hedhman wrote:
On Sat, Feb 12, 2011 at 8:41 PM, Mike McGrady
<mmcgr...@topiatechnology.com> wrote:
Isn't OSGi now distributed? See Fuse 4.0.
OSGi has a specification for remote services and how to express
capabilities vs requirements, but the actual transport as such is left
out, and it hooks into new APIs that the framework has to expose to
intercept lookup and registration of services.
Do, yes, what I mention is part of the OSGi scope, but since the River
community has decided to not work together with OSGi (I think I
brought that up first time in 2006 or so), similar functionality
should be part of Jini. Java is no longer a "single platform", as it
was in 1999 when Jini came about.
Byte codes is another example of 'service proxy selection' constraints
that come to mind. Native code could be another. Security permissions
should probably also be 'advertised' in advanced. I think all this
need to be speced out, for River to become interoperable, as Jini once
promised.
So, I think the actual problem is not that it can't be done, or that
people are not doing it, but Jini's failure initially (IMHO) was the
lack of interoperbility enablers, that there were no standards on
top.
The only difference between Jini and existing technologies such as DNS for
lookup, and SOAP/CORBA/Whatever for interchanging information is ... Mobile
Code. In order for there to be "mobile code", there has to be a "platform
standard." For Jini, that platform is the JVM. You can't send code around
between machines without some kind of "standard runtime environment."
If you don't understand/need mobile code as a solution to "correct, continuous
integration", then yes, you'll look at Jini and say "It does exactly what I
already can do, why would I use it?"
The reason why HTML and then Javascript and other browser processed, "language
based technologies" are successful today, is because people accepted them as
practical solutions.
What happened is that people considered Java more of an "OS choice" or "OS
Vendor Choice" instead of as a "network application platform." The whole MS vs
Sun and the silly Sun anti MS banter (in an open world, why do we need Gates
etc) just fueled the fire and made people have to draw a line in the sand and
choose one vs the other it seems to me.
> People spoke of "there could be a Printer interface" but no one
said "This is the base Printer interface, and extensions to it is made
in this way...".
What happened was that a bunch of printer vendors did in fact try and create a
printing standard. It was going strong for quite some time. But, eventually,
it all came down to the disaster of JDK 1.2 that made using Java on a printer
not an option. JDK1.2 was so unusable as to make nearly all essential
applications feel like windows.
Sun and its top level people apologized profusely at the onset of JDK1.3 for the
mistakes of the 1.2 "releases".
And one starting point is the "environment", the first stepping stone
of requirements vs capabilities matching...
That environment, which specifies all requirements and capabilites is "the JVM"
as a starting point. After that, it is necessary, from a deployment perspective
for all JVM based software, to manage the JMM, JVM and JLS requirements for your
needs.
What is happening now with the movement away from 1.4, is no different from what
happened when 1.1 and 1.2 and 1.3 disappeared from availability with the release
of Jini 2.0 which required JDK/JLS 1.4 features.
Jini together with Java can provide an excellent distributed networking
application platform. But, you have to understand when the "excellence" comes
from in order to appreciate it, and as hard nosed as it sounds, there's nothing
that Jini needs to do to work with other technologies. Instead, there are
interface points now which exist because of JERI to do things very close to the
client and server instead of having to add a tier into your application
environment. The invocation layer allows you to send an endpoint implementation
to a Jini client that can talk directly to other technologies which can be
downloaded and ran in such a JVM.
From the other perspective, a DNS-SD or SOAP or other interface point can be
built into any application, and a Jini service can "lookup" those
implementations with the appropriate technology discoveries, and then provide
proxies that are register in the ServiceRegistrar implementation available to
provide a gateway "service" between other Jini services and these
non-jini-technology based services.
The larger issue is that this hasn't been done, yet. The practical reason, is
that a vast majority of people using any one of the other technologies feel no
reason for Jini, because they are perhaps ignorant of the convincing facts, or
they have "other ways" to deal with the problems, and are content to just "do that".
I'm pretty much able to go on and on about how all the interactions are all
pretty much already possible, you just have to want to do it. There are bugs,
and there are some "missing features" for some cases I'm sure. But, the basic
design of what is already in River provides a huge amount of capability for
"integration" and "inter-working".
Niclas, I'd really like to here about very specific issues and cases which you
feel you "can't do today" from a "technology" perspective so that I can
understand where the gap is between what exists today and what you want Jini to
do in your environment/for your needs.
Gregg Wonderly
