The document provides an overview of the Jini architecture presented by Weisheng Si. It describes Jini as a distributed system architecture developed by Sun Microsystems that aims for "network plug and play". The key components of Jini include services, lookup services, proxy objects, and clients. It explains the service lookup process, including discovery, joining, and leasing. The discovery protocols of multicast request, unicast, and multicast announcement are covered. It also discusses how Jini uses Remote Method Invocation and TCP/IP in the architecture.
CIS14: Trusted Tokens: An Identity Game ChangerCloudIDSummit
Steven Lewis,
Advanced Systems Engineering Corporation
(ASEC)
Real-world contextual use case scenarios and the associated
token standards, specifications, and integration approach to
implement interoperable trust chains and identity propagation
within and across operating environments.
Istio Triangle Kubernetes Meetup Aug 2019Ram Vennam
It's been two years since we introduced the Istio project to the Triangle Kubernetes Meetup group. This presentation will be a brief re-introduction of the Istio project, and a summary of the updates to the Istio project since its 1.0 release.
CIS14: Trusted Tokens: An Identity Game ChangerCloudIDSummit
Steven Lewis,
Advanced Systems Engineering Corporation
(ASEC)
Real-world contextual use case scenarios and the associated
token standards, specifications, and integration approach to
implement interoperable trust chains and identity propagation
within and across operating environments.
Istio Triangle Kubernetes Meetup Aug 2019Ram Vennam
It's been two years since we introduced the Istio project to the Triangle Kubernetes Meetup group. This presentation will be a brief re-introduction of the Istio project, and a summary of the updates to the Istio project since its 1.0 release.
Lab 2:
Networking in the cloud
Overview:
As with any virtual environment networking is one of the most important aspects that must be addressed. Amazon’s Web Services gives you enough networking options to meet almost any need that could be done in a physical environment.
In this lab you will learn about:
· Public IP Addresses
· Private IP Addresses
· Elastic IP Addresses
· Virtual Private Clouds
· Internet gateways
· Amazon DNS & DHCP
Public IP, Private IP and Elastic IP Addresses
Public IP addresses are addresses that can be reached from anywhere on the Internet. These workas regular IP address that routable on the internet. When you launch an instance into EC2 your instance is automatically given a Public IP and a Private IP address. The private IP address works for Amazon’s internal networks and allows you to send traffic between your instances without having to route it through the public internet. This is important from a cost perspective because all internal traffic is free of charge. During this class you will not find it terribly important to limit the amount of external traffic but in a real world scenario the charges can quickly add up.
Public and private IP addresses are only assigned through DHCP which means that the addresses are not static. Every time you stop and start the instance the address will change. Using these default settings gives you very limited functionality for your instances.
Elastic IP addresses work a lot like public static addresses in that they are addresses that are given to your account that can be attached to any instance and it won’t change unlike your other IP addresses. If you want to run a temporary web server this would be an important option. Because the server is always up and you need to access it with a consistent address, you would attach an elastic IP to reach the server. What’s best about elastic IP addresses is that they can be moved from one instance to another and the address stays the same.
There is no charge for elastic IP addresses unless you have some that are not assigned to an instance. In this case amazon will charge the account a small fee for every hour that the IP address is free. If you are no longer in need of an elastic IP address remove it.
Note: When you stop an instance that is associated with an elastic IP address, the address will disassociate itself upon shutdown
Pinging Externally and internally
1. First launch two micro Linux instances like you did for Lab 1. Make sure they are both in the same security group.
2. Name one MachineA and the other MachineB.
3. Connect to MachineA via SSH
4. Looking at your instances from the Instance Library, select Machine A and scroll down to the DNS information.
5. Looking at the Public DNS you can see the public IP address for your instance. The address is the sequence of numbers between ec2 and .compute-X.amazonaws.com. In the screenshot above it is 50.16.55.68. This is the address that can be used to communica ...
Event Driven Services Part 2: Building Event-Driven Services with Apache KafkaBen Stopford
The second online talk in the Confluent Event Driven Services series covers how we build a shared narrative, using an event driven architecture, to conflate communication protocol and state transfer. We investigate how this leads to CQRS and discuss patterns for attaching Read-centric views to our canonical set of streams.
SERVICE DISCOVERY – A SURVEY AND COMPARISONijujournal
With the increasing number of services in the internet, companies’ intranets, and home networks: service
discovery becomes an integral part of modern networked system. This paper provides a comprehensive
survey of major solutions for service discovery. We cover techniques and features used in existing systems.
Although a few survey articles have been published on this object, our contribution focuses on comparing
and analyzing surveyed solutions according eight prime criteria, which we have defined before. This
comparison will be helpful to determine limits of existing discovery protocols and identify future research
opportunities in service discovery.
Building Event-Driven Services with Apache Kafkaconfluent
Should you use REST to sew services together? Is it better to use a richer, brokered protocol? This practical talk will dig into how we piece services together in event driven systems, how we we use a distributed log to create a central, persistent narrative and what benefits we reap from doing so.
Governments go digital and The Netherlands is no exception. Dutch law states that any citizen indicating a preference for digital communication, needs to be addressed in that manner. That includes any institution, whether it is Revenue Services, the Justice Department, or your local Municipality.
Legislation on digital communication is both very strict (GDPR) and very dynamic with yearly modifications aimed at supporting and protecting citizens in a way that they can trust and verify. Therefore, a communications system needs to be flexible and scalable (more than 5 million messages per day!).
For this purpose, we have built a communications system based on an Event Driven architecture. Of course, Kafka is the defacto solution of choice for a system like this. In this session we will demonstrate how Kafka and Event Driven architecture support citizen and government. We’ll tell you how we combine Kafka and Kubernetes to support replay and how we can always produce a watertight audit for anything that happened in digital correspondence.
If you’re interested in a little bit of hardcore tech and how event driven architecture works in massive scale in a highly secure GDPR compliant environment, then this talk is for you!
Lab 2:
Networking in the cloud
Overview:
As with any virtual environment networking is one of the most important aspects that must be addressed. Amazon’s Web Services gives you enough networking options to meet almost any need that could be done in a physical environment.
In this lab you will learn about:
· Public IP Addresses
· Private IP Addresses
· Elastic IP Addresses
· Virtual Private Clouds
· Internet gateways
· Amazon DNS & DHCP
Public IP, Private IP and Elastic IP Addresses
Public IP addresses are addresses that can be reached from anywhere on the Internet. These workas regular IP address that routable on the internet. When you launch an instance into EC2 your instance is automatically given a Public IP and a Private IP address. The private IP address works for Amazon’s internal networks and allows you to send traffic between your instances without having to route it through the public internet. This is important from a cost perspective because all internal traffic is free of charge. During this class you will not find it terribly important to limit the amount of external traffic but in a real world scenario the charges can quickly add up.
Public and private IP addresses are only assigned through DHCP which means that the addresses are not static. Every time you stop and start the instance the address will change. Using these default settings gives you very limited functionality for your instances.
Elastic IP addresses work a lot like public static addresses in that they are addresses that are given to your account that can be attached to any instance and it won’t change unlike your other IP addresses. If you want to run a temporary web server this would be an important option. Because the server is always up and you need to access it with a consistent address, you would attach an elastic IP to reach the server. What’s best about elastic IP addresses is that they can be moved from one instance to another and the address stays the same.
There is no charge for elastic IP addresses unless you have some that are not assigned to an instance. In this case amazon will charge the account a small fee for every hour that the IP address is free. If you are no longer in need of an elastic IP address remove it.
Note: When you stop an instance that is associated with an elastic IP address, the address will disassociate itself upon shutdown
Pinging Externally and internally
1. First launch two micro Linux instances like you did for Lab 1. Make sure they are both in the same security group.
2. Name one MachineA and the other MachineB.
3. Connect to MachineA via SSH
4. Looking at your instances from the Instance Library, select Machine A and scroll down to the DNS information.
5. Looking at the Public DNS you can see the public IP address for your instance. The address is the sequence of numbers between ec2 and .compute-X.amazonaws.com. In the screenshot above it is 50.16.55.68. This is the address that can be used to communica ...
Event Driven Services Part 2: Building Event-Driven Services with Apache KafkaBen Stopford
The second online talk in the Confluent Event Driven Services series covers how we build a shared narrative, using an event driven architecture, to conflate communication protocol and state transfer. We investigate how this leads to CQRS and discuss patterns for attaching Read-centric views to our canonical set of streams.
SERVICE DISCOVERY – A SURVEY AND COMPARISONijujournal
With the increasing number of services in the internet, companies’ intranets, and home networks: service
discovery becomes an integral part of modern networked system. This paper provides a comprehensive
survey of major solutions for service discovery. We cover techniques and features used in existing systems.
Although a few survey articles have been published on this object, our contribution focuses on comparing
and analyzing surveyed solutions according eight prime criteria, which we have defined before. This
comparison will be helpful to determine limits of existing discovery protocols and identify future research
opportunities in service discovery.
Building Event-Driven Services with Apache Kafkaconfluent
Should you use REST to sew services together? Is it better to use a richer, brokered protocol? This practical talk will dig into how we piece services together in event driven systems, how we we use a distributed log to create a central, persistent narrative and what benefits we reap from doing so.
Governments go digital and The Netherlands is no exception. Dutch law states that any citizen indicating a preference for digital communication, needs to be addressed in that manner. That includes any institution, whether it is Revenue Services, the Justice Department, or your local Municipality.
Legislation on digital communication is both very strict (GDPR) and very dynamic with yearly modifications aimed at supporting and protecting citizens in a way that they can trust and verify. Therefore, a communications system needs to be flexible and scalable (more than 5 million messages per day!).
For this purpose, we have built a communications system based on an Event Driven architecture. Of course, Kafka is the defacto solution of choice for a system like this. In this session we will demonstrate how Kafka and Event Driven architecture support citizen and government. We’ll tell you how we combine Kafka and Kubernetes to support replay and how we can always produce a watertight audit for anything that happened in digital correspondence.
If you’re interested in a little bit of hardcore tech and how event driven architecture works in massive scale in a highly secure GDPR compliant environment, then this talk is for you!
2024.06.01 Introducing a competency framework for languag learning materials ...Sandy Millin
http://sandymillin.wordpress.com/iateflwebinar2024
Published classroom materials form the basis of syllabuses, drive teacher professional development, and have a potentially huge influence on learners, teachers and education systems. All teachers also create their own materials, whether a few sentences on a blackboard, a highly-structured fully-realised online course, or anything in between. Despite this, the knowledge and skills needed to create effective language learning materials are rarely part of teacher training, and are mostly learnt by trial and error.
Knowledge and skills frameworks, generally called competency frameworks, for ELT teachers, trainers and managers have existed for a few years now. However, until I created one for my MA dissertation, there wasn’t one drawing together what we need to know and do to be able to effectively produce language learning materials.
This webinar will introduce you to my framework, highlighting the key competencies I identified from my research. It will also show how anybody involved in language teaching (any language, not just English!), teacher training, managing schools or developing language learning materials can benefit from using the framework.
How to Split Bills in the Odoo 17 POS ModuleCeline George
Bills have a main role in point of sale procedure. It will help to track sales, handling payments and giving receipts to customers. Bill splitting also has an important role in POS. For example, If some friends come together for dinner and if they want to divide the bill then it is possible by POS bill splitting. This slide will show how to split bills in odoo 17 POS.
How to Make a Field invisible in Odoo 17Celine George
It is possible to hide or invisible some fields in odoo. Commonly using “invisible” attribute in the field definition to invisible the fields. This slide will show how to make a field invisible in odoo 17.
We all have good and bad thoughts from time to time and situation to situation. We are bombarded daily with spiraling thoughts(both negative and positive) creating all-consuming feel , making us difficult to manage with associated suffering. Good thoughts are like our Mob Signal (Positive thought) amidst noise(negative thought) in the atmosphere. Negative thoughts like noise outweigh positive thoughts. These thoughts often create unwanted confusion, trouble, stress and frustration in our mind as well as chaos in our physical world. Negative thoughts are also known as “distorted thinking”.
Operation “Blue Star” is the only event in the history of Independent India where the state went into war with its own people. Even after about 40 years it is not clear if it was culmination of states anger over people of the region, a political game of power or start of dictatorial chapter in the democratic setup.
The people of Punjab felt alienated from main stream due to denial of their just demands during a long democratic struggle since independence. As it happen all over the word, it led to militant struggle with great loss of lives of military, police and civilian personnel. Killing of Indira Gandhi and massacre of innocent Sikhs in Delhi and other India cities was also associated with this movement.
How to Create Map Views in the Odoo 17 ERPCeline George
The map views are useful for providing a geographical representation of data. They allow users to visualize and analyze the data in a more intuitive manner.
Palestine last event orientationfvgnh .pptxRaedMohamed3
An EFL lesson about the current events in Palestine. It is intended to be for intermediate students who wish to increase their listening skills through a short lesson in power point.
Ethnobotany and Ethnopharmacology:
Ethnobotany in herbal drug evaluation,
Impact of Ethnobotany in traditional medicine,
New development in herbals,
Bio-prospecting tools for drug discovery,
Role of Ethnopharmacology in drug evaluation,
Reverse Pharmacology.
1. Nov 6, 2000 CS851 Ubiquitous Computing 1
The Jini Architecture
Speaker: Weisheng Si
Dept. of Computer Science
University of Virginia
2. Nov 6, 2000 CS851 Ubiquitous Computing 2
Outline
• What is Jini?
• Jini architecture overview
• Service lookup process
• Distributed events
• How is Jini related to the RMI
• Comparison with HAVi
• Comparison with CORBA
• My example
3. Nov 6, 2000 CS851 Ubiquitous Computing 3
What is Jini?
• Jini is a distributed system architecture
developed by Sun Microsystems, Inc.
• Its main goal is “network plug and play”.
• Jini is not an acronym, it’s coined by one of
its designers--Bill Joy.
• You can think it as standing for “Jini Is Not
Initials”.
4. Nov 6, 2000 CS851 Ubiquitous Computing 4
Architecture Overview
Jini Services
Remote Method Invocation
TCP/IP
The Jini Architecture
Java Virtual Machine
Data Link Layer
5. Nov 6, 2000 CS851 Ubiquitous Computing 5
Basic Components of Jini
• Service : entity that can be used by a person, a device,
or another service, for example, printing a document,
displaying videos, etc.
• The lookup service : providing a central registry of
services; and the clients use it to locate a service that he
wants.
• Proxy object and its attributes : the object implements
all the interfaces provided by the remote service; and
attributes are used to distinguish the object from other
objects of the same type.
• Client : entity who requests services.
6. Nov 6, 2000 CS851 Ubiquitous Computing 6
A simplified example :
A Printer
Proxy Object
Printer Attributes
The Lookup Service
A Camera
The Lookup Service
Proxy Object
Printer Attributes
A Camera
Proxy Object
7. Nov 6, 2000 CS851 Ubiquitous Computing 7
The more complete scenario
1. A new printer is set up in the network.
2. The printer sends a “looking for lookup services” message to the local network.
3. Each lookup service on the network responds with a proxy for itself.
4. The printer registers its proxy object and attributes with each lookup service
using the proxy of each lookup service.
5. A man with a digital camera comes into this network, and he wants to print out
a new picture.
6. The camera sends “ looking for lookup services” messages to the local network.
7. Each lookup service in the network responds with a proxy for itself.
8. The camera searches for types of services it needs using the proxies of one or more
lookup services. The lookup service returns one or more matching proxy objects,
and the client distinguish them further by their attributes.
9. The exactly matched proxy is downloaded to the camera. Then the
camera begins to use the proxy to interact with the printer to print the picture.
8. Nov 6, 2000 CS851 Ubiquitous Computing 8
What happens in a Jini environment?
For a service:
Discovery : sends a “looking for lookup services” message to all the local lookup
services and downloads their proxy objects.
Join : uses the downloaded proxy object to register its proxy object and attributes
with each lookup service.
Renew : renews its registration at the lookup services. (talk about later)
For a client:
Discovery : sends a “looking for lookup services” message to all the local lookup
services and downloads their proxy objects. Then it picks
up the service that it wants by using the proxies of the lookup services.
For a lookup service:
Here I am : sends a “Here I am” message periodically to the local network in case
that some services maybe fail to register previously due to the network
failure or some other reasons.
9. Nov 6, 2000 CS851 Ubiquitous Computing 9
The Service Lookup Process
• Service ID: each service, including the lookup service, has
an ID that is unique in the Jini environment.
• Group : a group can be represented by any arbitrary string.
• A client can use group to identify a set of services that it
wishes to look up.
• The lookup service can use group to filter the lookup
requests.
• A group with an empty string as name means “public
group”, which will actually match all groups.
10. Nov 6, 2000 CS851 Ubiquitous Computing 10
The Service Lookup Process(cont’d)
• The Discovery Protocols : are used by a client or a
service to find out the lookup services and
download their proxy objects.
• The Leasing Mechanism : a lease is a period of
time during which the service is registered. If the
lease expires and the service doesn’t renew it, the
service will be discarded by the lookup service.
• The Join Protocol : is used by the service to
register itself with a lookup service.
11. Nov 6, 2000 CS851 Ubiquitous Computing 11
The Discovery Protocols
• Multicast Request Protocol
• Unicast discovery protocol
• Multicast Announcement Protocol
Three Protocols are used in the discovery phase:
12. Nov 6, 2000 CS851 Ubiquitous Computing 12
The Multicast Request Protocol
• The Multicast Request Protocol is initiated by a discovering
entity(a client or a service) to locate a lookup service.
• It uses 2 connections: one is the multicast UDP to send the
“looking for lookup service” message to the network, the other
is a TCP connection to wait for the lookup service to connect
back.
• It uses the TCP connection to download the proxy object of the
lookup service.
13. Nov 6, 2000 CS851 Ubiquitous Computing 13
The Discovering Entity The Lookup Service
2. The discovering entity first
sets up a TCP server.
The multicast response service
1. Construct a multicast UDP
socket, listening to the multicast
request.
3. Constructs a multicast UDP
socket, then sends its request
for lookup services to the network.
4. If the DE’s groups match the
groups to which it provides services,
it connects to the DE’s multicast
response server, and passes its proxy
object to the DE.
The multicast response service
14. Nov 6, 2000 CS851 Ubiquitous Computing 14
The Unicast Discovery Protocol
• By multicast, a discovering entity can only find out the lookup
services in the local network.
• What if a user want to access a Jini service in another
network? Use the Unicast Discovery Protocol!
• The client needs to be told about the location of the remote
lookup service.
• Then the client directly establishes the TCP connection to the
lookup service and downloads the lookup service’s proxy
object.
15. Nov 6, 2000 CS851 Ubiquitous Computing 15
The Multicast Announcement Protocol
• The Multicast Announcement Protocol is initiated by the
lookup service to announce its existence.
• It also uses 2 connections: one is the multicast UDP to send the
“Here I am” message to the network, the other is a TCP
connection to wait for the discovering entity to establish a
download connection. In fact, this TCP connection is the same
connection as used in the Unicast Discovery Protocol.
• It uses the TCP connection to transfer the proxy object of the
lookup service to the discovering entity.
16. Nov 6, 2000 CS851 Ubiquitous Computing 16
The Discovering Entity The Lookup Service
1. Establishes TCP unicast
discovery server.
The unicast discovery server
2. Constructs a UDP multicast
socket, periodically sends out
the “Here I am” message.
1.Establishes a set of service IDs
of lookup services from which it
already heard, then constructs
socket waiting for the arriving of
the multicast announcement.
Service IDs
2. For each announcement received,
it determines whether the service ID
is already in the set and whether it is
interested in the groups of the lookup
service.
3. If the service ID isn’t in the set
and it is interested in the groups, it
connects to the unicast server to get
the proxy of the lookup service and
then add the new ID into the set.
The unicast discovery server
17. Nov 6, 2000 CS851 Ubiquitous Computing 17
• When a service registers with a lookup service, it gets back a lease
on its presence in the lookup service.
• If a service wants to maintain its presence, it must periodically
renew the lease at the lookup service.
• Any network or host failure will force the removal of the
unreachable services, which guarantees that the status of the
network is almost always current.
• It’s a self-healing mechanism. For example, when a network
failure isolates a service from a lookup service, the service will be
evicted from the lookup service because it can’t renew its lease.
And when the network is fixed, the service will receive a “Here I
am” message, and then it can join the lookup service again.
The Leasing Mechanism
18. Nov 6, 2000 CS851 Ubiquitous Computing 18
The Join Protocol
A service must maintain certain items of its state. These items are
as follows:
1. Its service ID : A new service will not be assigned a service ID until it is
started for the first time. After a service has been assigned a service ID, it
must continue to use it across all lookup services.
2. Set of attributes : used to distinguish the service from other services.
3. Set of groups : the groups that this service wishes to participate.
4. Set of specific lookup services : the lookup services that this service has
registered with. (by remembering their service IDs)
19. Nov 6, 2000 CS851 Ubiquitous Computing 19
The Join Protocol(cont’d)
3. The Join Protocol happens after the discovery process, and is
accomplished by using the downloaded proxy of the lookup service.
2. For example, if a service is asked to change the set of attributes
with which it registers itself, it first modifies the set of attributes in
its storage, then it performs the requested change at each lookup
service with which it is registered.
1. The Join Protocol is used to register/unregister a service with a
lookup service, or to maintain those items of its state, such as
changing its groups, attributes, etc.
20. Nov 6, 2000 CS851 Ubiquitous Computing 20
• Though the Jini specification doesn’t explicitly say that Jini
relies on the TCP/IP, but actually it does.
• The Jini specification says:
Some Network Details
if (TCP/IP is based on)
{
the multicast request uses the multicast IP address 224.0.1.85 and
UDP port number 4160 by default;
the unicast discovery uses the TCP port number 4160 by default;
the multicast announcement uses the multicast IP address 224.0.1.84
by default;
}
Note: They are also called well-known multicast IP addresses and port
number for Jini.
21. Nov 6, 2000 CS851 Ubiquitous Computing 21
• Network delivery is unreliable: messages may be lost. Synchronous methods
requiring a reply may not work here.
• Network delivery has indefinite delay: messages may arrive at different times
to different listeners. So the state of an object as perceived by a listener at any
time may be inconsistent with the state perceived by others.
• A remote listener may have disappeared by the time the event occurs.
Listeners have to be allowed to ``time out'', like services do.
Distributed/Remote Event
Remote Event is different from the local event, in that:
Jini makes no assumptions about guarantees of delivery and
delivery in order. The event generator supplies a sequence
number that could be used to construct state and ordering
information. And the Leasing mechanism of event is also used.
22. Nov 6, 2000 CS851 Ubiquitous Computing 22
• Unlike the large number of event classes in the AWT and Swing,
Jini typically uses event of only one type, the RemoteEvent and
a small number of its subclasses.
• A RemoteEvent is serializable and can be moved around the
network to its listeners.
• The RemoteEventListener is the receiver of RemoteEvents. A
RemoteEventListener is defined by an interface that contains a
single method, “notify”, which informs interested listeners that
an event has occurred.
Distributed/Remote Event(cont’d)
23. Nov 6, 2000 CS851 Ubiquitous Computing 23
Registration and notification of Events
Registrant Event
Generator
Remote
Event
Listener
1. Registrant registers the
remote event listener with
the event generator
2. Event generator returns
an event registration for the
remote event listener to the
registrant
4. Event generator fires
a remote event to the
listener to indicate the
kind of event occurred
3. Registrant returns the
event registration to the remote
event listener.
24. Nov 6, 2000 CS851 Ubiquitous Computing 24
Two examples of using events
• Service starting or closing : A client can
know if a service is available immediately
by registering the corresponding events,
without checking with the lookup services.
• Email notification : Once new emails arrive,
the email service will fire an event to the
email client, such that the email client
needn’t poll the email server.
25. Nov 6, 2000 CS851 Ubiquitous Computing 25
How is Jini related to the RMI
• RMI stands for Remote Method Invocation,
first introduced in JDK 1.1.
• You can think RMI is the RPC of Java, but
it has many enhanced features.
• The most fundamental enhancement is that
RMI supports the passing of the whole
object over the network, which is employed
by Jini.
26. Nov 6, 2000 CS851 Ubiquitous Computing 26
RMI Architecture
Client Program Server Program
Stub Skeleton
Java Remote Method Protocol
Transport Layer
Java Remote Method Protocol
27. Nov 6, 2000 CS851 Ubiquitous Computing 27
Running a typical RMI Application
rmiregistry
Application
Client
Application
Server
Appl_Stub.class
Web
Server
Appl_Stub.class
Naming.
rebind()
Naming.
lookup()
28. Nov 6, 2000 CS851 Ubiquitous Computing 28
Retrospect to the Jini
A Printer
Proxy Object
Printer Attributes
The Lookup Service
The Lookup Service
Proxy Object
Printer Attributes
A Camera
Proxy Object Any protocol is OK.
1. Proxy must be implemented by
the programmer, while stub is
automatically generated by the RMI
compiler “rmic”.
2. Proxy can communicate with the
service using its own protocol, and
the client doesn’t need to know about
it.
3. Proxy is the key role to achieve the
spontaneous use of the network.
29. Nov 6, 2000 CS851 Ubiquitous Computing 29
Where is RMI used?
Service
Lookup Service
Registrar
1. The proxy object of the lookup service is called Registrar.
2. After the discovery phase, the Registrar is downloaded to the Service.
3. The service uses the Registrar to register with the lookup service, and the protocol
used is the RMI in Sun’s implementation(Jini1.1 Starter Kit).
4. In Sun’s implementation of Jini, the lookup service is named “Reggie” and it needs
“rmid” and a web server as the support services.
Discovery
Service
Registrar
Lookup Service
Join, using RMI
Service
Registrar
Lookup Service
Proxy of the Service
rmid Web Server
Stub used by Registrar
30. Nov 6, 2000 CS851 Ubiquitous Computing 30
Comparison with HAVi
1. HAVi is constructed on the IEC
61883.1 function control protocol and
the IEEE 1394 bus standard.
1. Jini relies on TCP/IP as its lower
layer.
HAVi messaging
IEC 61883 FCP
IEEE 1394
Standard
Jini Services
RMI
TCP/IP
The HAVi Architecture The Jini Architecture
JVM
Data Link Layer
31. Nov 6, 2000 CS851 Ubiquitous Computing 31
Comparison with HAVi(Cont’d)
2. HAVi works under a fully
distributed peer-to-peer fashion. Each
Full AV device possesses all the
software elements such as DCM
manager, registry, and messaging
system. There can be no central
controller.
3. HAVi’s “Discovery” means to
detect that a device is added or
removed from the network.
HAVi’s “Lookup” means to search
each device’s registry to find out the
service it wants, the same meaning as
“discovery” in Jini.
2. A Jini environment must have at
least one lookup service to serve as
the central registry.
3. Jini’s “Discovery” means to
discover the lookup services.
32. Nov 6, 2000 CS851 Ubiquitous Computing 32
Comparison with HAVi(Cont’d)
4. The IEEE 1394 supports the
dynamic device actions such as hot
plugging and unplugging. When the
1394 bus detects a topology change, it
will transmit a bus indication to all the
devices in the network. Then the
Communication Media Manager of
each device will handle such an
indication.
4. Jini uses the Leasing mechanism as
well as the lookup service to achieve
the dynamic change of the network.
33. Nov 6, 2000 CS851 Ubiquitous Computing 33
Comparison with CORBA
1. CORBA is language independent. It
uses OMG IDL, and has IDL
compilers for most of the popular
programming languages.
2. The current version of CORBA
doesn’t support object serialization,
but it soon will.
3. CORBA uses the Naming/Directory
service to obtain the reference to the
remote object.
4. It uses unicast for the service
lookup.
1. Jini relies on Java. It uses Java
“interface” to describe the interface to
the remote services.
2. The capability of “moving code” is
one of the most important features of
Jini.
3. Jini uses the lookup services to
obtain the proxy to interact with the
remote service. It searches not only by
the type but also by the attributes.
4. It multicasts its service lookup
request to the local network.
34. Nov 6, 2000 CS851 Ubiquitous Computing 34
Comparison with CORBA(cont’d)
5. CORBA has no Leasing
mechanism.
6. CORBA focuses on “Object”.
7. CORBA uses the GIOP to define
the format of the messages, and IIOP
to define the exchanging process of
these messages. GIOP adopts the
CDR representation. All these enable
that ORB can be developed
independently by any vendor.
5. Jini uses the Leasing mechanism as
well as the lookup service to achieve the
“network plug and play”.
6. Jini focuses on “Service”. This is
because the designers of Jini believe that
the distributed object transparency is
impossible.
7. Jini employs a variety of protocols:
multicast UDP, RMI over JRMP,etc. And
any other protocol can be used by the
“proxy” and “service” communication.
JRMP is only partially specified, and the
next version RMI, called “RMI-IIOP”,
will use IIOP instead.
35. Nov 6, 2000 CS851 Ubiquitous Computing 35
Comparison with CORBA(cont’d)
8. In CORBA, a programmer only
need to develop the client and the
server program. The stub and skeleton
are automatically generated by the
IDL compiler. No transmission of stub
is required.
8. In Jini, a programmer needs to
develop the client, the proxy, and the
server. In RMI, the stub is generated
by the RMI compiler using the server
source code and needs to be
transmitted to the client side.
37. Nov 6, 2000 CS851 Ubiquitous Computing 37
The Smart Olsson Hall
Lookup Service A
Proxy of CS-BW1
Proxy of CS-BW2
Lookup Service B
Proxy of CS-BW1
Proxy of CS-BW2
CS-BW1 CS-BW2
Evans Knight
Lookup Service A
Proxy of CS-BW1
Lookup Service B
Proxy of CS-BW2
Lookup Service A
Proxy of CS-BW1
Proxy of CS-BW2
Lookup Service B
Proxy of CS-BW2
Proxy of CS-BW1
Visitor
Visitor
Proxy of CS-BW1
38. Nov 6, 2000 CS851 Ubiquitous Computing 38
Thank you!