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.
