river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Brouwer (JIRA)" <j...@apache.org>
Subject [jira] Created: (RIVER-279) Create a Jini Platform Specification that defines the minimum/maximum set of specifications that make up the platform
Date Fri, 14 Dec 2007 11:05:44 GMT
Create a Jini Platform Specification that defines the minimum/maximum set of specifications
that make up the platform
---------------------------------------------------------------------------------------------------------------------

                 Key: RIVER-279
                 URL: https://issues.apache.org/jira/browse/RIVER-279
             Project: River
          Issue Type: Improvement
          Components: other
    Affects Versions: jtsk_2.1
            Reporter: Mark Brouwer


One problem (in issue writers humble opinion) is that Jini means a lot of things to people,
for some it is a way of thinking, for others it represents the codebase formerly known as
the Jini Technology Starter Kit (JTSK) and for others (which includes issue submitter) it
represents the concepts, ideas, etc. written in the document [Jini Technology Core Platform
Specification|http://www.sun.com/software/jini/specs/jini1.1html/coreTOC.html] and at a higher
level in the document [Jini Architecture Specification|http://www.sun.com/software/jini/specs/jini1.1html/jini-spec.html].
With the arrival of the JTSK 2.0 (which is an implementation of many new and upgraded Jini
related specifications) that brought to us distributed security amongst other enhancements
to the RMI protocol stack this notion of Jini Technology Core Platform seemed to have been
dropped.

As interoperability is key to any distributed technology and especially in the context of
mobile code I believe we need an interoperability specification that would work for (modern)
Jini in the same way is that it works for Java SE Platform, call it the resurrection of the
Jini Platform. For more details about the implications, benefits, etc of a common Jini Platform
please see this [presentation|http://www.cheiron.org/misc/jcm/jcm8.pdf] given at JCM8.

Although no doubt there will stay a lot of misconception what Jini really represents (the
same as with Java SE or Java EE) it gives us at least a pointer to a document that explains
exactly what a Jini Platform represents and what a Jini compliant or computing platform should
comply to. For companies and open source projects that provide distributed computing platforms
built on top of the various Jini specifications the existence of such a Jini Platform allows
them to indicate that what they provide is compliant to the Jini Platform.

A Jini Platform specification will list the environmental dependencies, specifies the current
specifications that make up the Platform and can evolve over time. It must only specify that
what is important for interoperability at the network boundary, it is not to determine or
set requirements for capabilities of the server side platform. Therefore it is not intended
to give any party in the Jini ecosystem an advantage over the other, it is only to increase
the chance solutions from various parties can work together in creating a software system,
although I realize the latter might be so 20th century ;-) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message