Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4D48B214.90802@zeus.net.au>
Date: Wed, 02 Feb 2011 11:23:32 +1000
From: Peter Firmstone <jini@zeus.net.au>
User-Agent: Thunderbird 2.0.0.14 (X11/20080531)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: MarshalledServiceItem
References: <4D45C8A5.6010309@zeus.net.au>
	<52044E7A-F5A2-4470-AA5F-9922C0328639@wonderly.org>
	<AANLkTi=j8FTTisHLAD_d14NzZy10PTW=E1fm7-TKFWa2@mail.gmail.com>
	<4D47E6AD.8060100@zeus.net.au>
 <AANLkTi=d6=dhckC2SrTXUnTJrxv+Yf_a9JH6zyvNEGnM@mail.gmail.com>
 <4D47FC40.10001@qcg.nl> <4D481903.4010206@acm.org>
In-Reply-To: <4D481903.4010206@acm.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Patricia Shanahan wrote:
> Sim IJskes - QCG wrote:
>> On 01-02-11 12:40, Dan Creswell wrote:
>>> Ah, I know Sim is gonna hate this but I feel the need to retain full 
>>> context
>>> for now....
>>
>> What i would prefer to see is:
>> - a use case defining internet deployment
>> - a proof of concept prototype implementing this use case
>> - define lessons learned
>>
>> If it turns out that there is something in the lookup what needs 
>> improvement, then we can change that.
>>
>> Better not use internet deployment in requirements discussions before 
>> whe have defined what it is. Thats too vague for me.
>
> I agree.
>
> If implementing Internet deployment is either impossible regardless of 
> the proposed changes, or can be done well without them, then making 
> the changes would be a mistake.
>
> The easiest way to be sure about this is a use-case and proof of 
> concept prototype. The prototype can be used to demonstrate how 
> proposed River changes contribute to implementing the use-case.
>
> Patricia
>
>

I think we need a standard process for developing and proposing new 
components.  Gregg provided his reef project in 2006, but I don't think 
anyone from the River / Jini community has given much feedback or been 
interested in changes to lookup semantics.

Jini was targeted at devices, and corporate networks, but Jini services 
are not made available publicly over the internet.  Jini was designed 
with failure in mind and the 8 fallacies of distributed computing.  The 
internet is a form of distributed computing.

Jini works well on trusted networks, but untrusted networks are difficult.

Jini works well on networks with high bandwidth low latency, but has 
usability issues with low bandwidth and high latency connections, or in 
Gregg's case, probably has some issues with high bandwith networks also.

Gregg and Chris have come up with solutions to low bandwith, high 
latency networks, but these are still private networks.

So to create a proof of concept prototype for the internet there's a 
need to address at least the following issues:

    * Low bandwidth high latency connections.
    * Security on untrusted networks.
    * Firewall traversal.
    * Improved service search ability.
    * Discovery of internet provided services.

I apologise in advance for use cases, which may or may not be a correct 
interpretation of what "Use case" means.

A complex use case might be:

One company has a contract with a second company, a supplier which 
provides parts and components the first company uses in manufacture of 
it's products, the two company's have formed a contract based on cost 
plus markup, where the first company uses the buying power of the second 
to take advantage of volume discounts, the companies have agreed on 
standard interfaces for jini services.  The second company engages 
multiple manufacturers of components, these manufacturers provide supply 
chain product information, such as models, fit up drawings, pictures and 
information relating to the product it sells, each manufacturer utilises 
it's own internal systems and use their own Service UI's to display 
information regarding supplied components for downstream purchasers and 
up to date service bulletins for customers maintenance advise systems, 
they also implement standard agreed service interfaces for commerce.

The second company, the supplier, also has other customers, these 
company's use the services to enable their different systems to interact 
using Jini service interfaces and Service UI's, rather than protocols.  
This needs to be done securely and records of all transactions need to 
be retained by all parties.

These services are performed over the internet, rather than through 
virtual private networks, some applications are required in field for 
maintenance and service bulletins, where the network may be third party 
or public.

A simple use case might be:

A user browses services online, that perform various functions and are 
found using a Jini service browser, all Service UI are downloaded on 
demand, applications might range from online sellers and purchasers, to 
interactive information, games or online banking.

Cheers,

Peter.