Unit # VI

Recent Trends in Distributed

Systems
Prepared by,
Ms. S. S. Kekan
Syllabus
• Recent Trends: Introduction, Portable and handheld Devices,
Wearable devices, Devices embedded in appliances, Parallel Virtual
Machine (PVM), Jini, Service Oriented Architecture, The Future of
Recent Trends.
• Tools for Distributed System Monitoring: Prometheus, Zabbix, Nagios
• Case Studies: Mach, Chorus
Recent Trends : Introduction
• Distributed systems are undergoing a period of significant change and
this can be traced back to a number of influential trends:
• The emergence of pervasive networking technology;
• The emergence of ubiquitous computing coupled with the desire to support
user mobility in distributed systems;
• The increasing demand for multimedia services;
• The view of distributed systems as a utility.
Devices used in Recent Trends of Distributed
System
• Portable Devices

• Handheld Devices

• Wearable Devices

• Devices embedded in appliances

Devices used in Recent Trends of Distributed
System
• Technological advances in device miniaturization and wireless
networking have led increasingly to the integration of small and
portable computing devices into distributed systems.
• These devices include:
• Laptop computers.
• Handheld devices, including mobile phones, smart phones, GPS-enabled
devices, pagers, personal digital assistants (PDAs), video cameras and digital
cameras.
• Wearable devices, such as smart watches with functionality similar to a PDA.
• Devices embedded in appliances such as washing machines, hi-fi systems,
cars and refrigerators.
Devices used in Recent Trends of Distributed
System
• The portability of many of these devices, together with their ability to connect
conveniently to networks in different places, makes mobile computing possible.
• Mobile computing is the performance of computing tasks while the user is on the
move, or visiting places other than their usual environment. In mobile computing,
users who are away from their ‘home’ intranet (the intranet at work, or their
residence) are still provided with access to resources via the devices they carry
with them.
• They can continue to access the Internet; they can continue to access resources in
their home intranet; and there is increasing provision for users to utilize resources
such as printers or even sales points that are conveniently nearby as they move
around.
• The latter is also known as location-aware or context-aware computing. Mobility
introduces a number of challenges for distributed systems, including the need to
deal with variable connectivity and indeed disconnection, and the need to maintain
operation in the face of device mobility.
Devices used in Recent Trends of Distributed
System

Portable and handheld devices in a distributed system

Devices used in Recent Trends of Distributed
System
Ubiquitous computing is the harnessing of many small, cheap computational devices
that are present in users’ physical environments, including the home, office and even
natural settings. The term ‘ubiquitous’ is intended to suggest that small computing
devices will eventually become so pervasive in everyday objects that they are
scarcely noticed. That is, their computational behaviour will be transparently and
intimately tied up with their physical function.

The presence of computers everywhere only becomes useful when they can
communicate with one another. For example, it may be convenient for users to
control their washing machine or their entertainment system from their phone or a
‘universal remote control’ device in the home. Equally, the washing machine could
notify the user via a smart badge or phone when the washing is done.
Devices used in Recent Trends of Distributed
System
Ubiquitous and mobile computing overlap, since the mobile user can in principle
benefit from computers that are everywhere. But they are distinct, in general.
Ubiquitous computing could benefit users while they remain in a single
environment such as the home or a hospital. Similarly, mobile computing has
advantages even if it involves only conventional, discrete computers and devices
such as laptops and printers.
Parallel Virtual Machine (PVM)
• A parallel virtual machine (PVM) is a distributed computing system
that’s created through a series of parallel computers, which are all
merged together to be displayed as a unified virtual machine. This
software framework creates a distributed computing architecture
from a parallel connected system that works as a single unit to
process any high-end computing task.
• PVM was a step towards modern trends in distributed
processing and grid computing but has, since the mid-1990s, largely
been supplanted by the much more successful MPI standard for
message passing on parallel machines. PVM is free software, released
under both the BSD License and the GNU General Public License.
Parallel Virtual Machine (PVM)
• Advantages of PVM
• Portability: Probably the most portable message passing library available
• Scalable Parallelism
• Fault tolerance through dynamic addition and deletion of hosts/processes.
• Easy to install and use
• Popular - a widely used parallel message passing library
• Just about any UNIX computer (where you have an account) on the Internet can become part
of your parallel virtual machine.
• Flexible
• Easy definition and modification of your parallel virtual machine
• Arbitrary control and dependency structures - your application "decides":
• where and when tasks are spawned and terminated
• which machines to add or delete from your parallel virtual machine
• how tasks communicate and/or synchronize with each other
Parallel Virtual Machine (PVM)
• Disadvantages of PVM
• Performance: Depending upon the architecture and implementation, PVM may be slower
than other native message passing languages.
• PVM is not a standard (unlike MPI)
• It is deficient in some of the message passing functionality.
• Programmer has to explicitly implement all parallelization details.
• Difficult debugging
Parallel Virtual Machine (PVM)
• PVM Components
Components are the parts of your Parallel Virtual Machine
responsible for things such as:
• communication
• process control
• the programming interface for the user.
• There are two components of PVM-
• the PVM Daemon and
• the PVM Libraries.
Parallel Virtual Machine (PVM)
• PVM Daemon (pvmd3) (First PVM Component)
• The PVM daemon pvmd3 is a Unix process which oversees the operation of user
processes within a PVM application and coordinates inter-machine PVM
communications.
• One and only one daemon runs on each machine configured into your parallel virtual
machine. However, other users, with their own parallel virtual machines, will have
their own pvmd3s running.
• The "master" PVM daemon is the first PVM daemon started and is responsible for
starting all other PVM daemons in your parallel virtual machine. Typically started on
your login machine.
• Each daemon maintains a table of configuration and process information relative to
your parallel virtual machine.
• User processes communicate with each other through the daemons:
• they first talk to their local daemon via the library interface routines.
• local daemon then sends/receives messages to/from remote host daemons.
Parallel Virtual Machine (PVM)
PVM Libraries (Second PVM Component)
•The three PVM libraries are:
•libpvm3.a - library of C language interface routines. Always required.
•libfpvm3.a - additionally required for Fortran codes
•libgpvm3.a - required for use with dynamic groups
•Contain simple subroutine calls that the application programmer embeds in concurrent or parallel application
code. Provide the ability to:
•initiate and terminate processes
•pack, send, receive and broadcast messages
•synchronize via barriers
•query and dynamically change configuration of the parallel virtual machine
•Library routines do not directly communicate to other processes. Instead, they send commands to the local
daemon and receive status information back.
•Can be installed in user filespace - default location is $HOME/pvm3/lib.
•External Data Representation (XDR) format conversion is performed automatically between hosts of different
architectures. This is the default.
Jini
• Jini is a service-oriented architecture that defines a programming model
that both exploits and extends Java technology.
• This programming model enables the construction of secure, distributed
systems consisting of federations of well-behaved network services.
• Jini helps to build networks that are scalable and flexible, which are
required attributes in distributed computing scenarios.
• Jini’s main objective is to shift the focus of distributed computing from a
disk-drive-oriented approach to a network-adaptive approach by
developing scalable, evolvable and flexible dynamic computing
environments.
• Jini makes resources over a network look like local resources.
• Jini may also be referred to as Apache River.
Jini
• Jini was introduced in July 1998 by Sun Microsystems. It consists of a set of
specifications and a starter kit, which includes the implementation of Jini
technology. Both are released under the open-source Apache 2.0 License.
Jini is implemented in the Java programming language and is similar to Java
remote method invocation, except that it is more advanced.
• Jini provides desirable features and facilities like non protocol dependence
and code mobility. In fact, code mobility is the key concept. Jini not only
allows for the addition of printers, storage and other devices to a network,
it also allows the devices to be detected automatically over the network
without having to reboot the system. Hardware devices declare to their
own operating systems as well as to other computers, devices and users on
the network that they have been added and are available for use. This is
possible because the devices define themselves to a network device
registry soon after they have been added.
Jini
• Jini has the following key advantages:
• Provides stable networking solutions
• Helps in upgrading systems
• Helps to keep old clients running while adding new ones
• Helps build scalable, dynamic and flexible networks
Jini Architecture
• The Jini architecture is divided into three main parts:
• Client: The user who accesses the resources shared over a network
• Server: The system to which the resources are attached
• Lookup Service: Services for resources such as printers, storage devices and
speakers, which are attached to the server and made available to clients over
the network
Working of Jini
• Jini defines a runtime infrastructure that resides on the network and
provides mechanisms that enable you to add, remove, locate, and access
services.
• The runtime infrastructure resides on the network in three places: in
lookup services that sit on the network; in the service providers (such as
Jini-enabled devices); and in clients.
• Lookup services are the central organizing mechanism for Jini-based
systems.
• When new services become available on the network, they register
themselves with a lookup service.
• When clients wish to locate a service to assist with some task, they consult
a lookup service.
Working of Jini
• The runtime infrastructure uses
• one network-level protocol, called discovery,
• two object-level protocols, called join and lookup.
• Discovery enables clients and services to locate lookup services.
• Join enables a service to register itself in a lookup service.
• Lookup enables a client to query a lookup service for services that
can help the client accomplish its goals.
Working of Jini
• The discovery process
• Discovery works like this: Imagine you have a Jini-enabled disk drive that offers a
persistent storage service. As soon as you connect the drive to the network, it
broadcasts a presence announcement by dropping a multicast packet onto a well-
known port. Included in the presence announcement is an IP address and port
number where the disk drive can be contacted by a lookup service.
• Lookup services monitor the well-known port for presence announcement packets.
When a lookup service receives a presence announcement, it opens and inspects the
packet. The packet contains information that enables the lookup service to
determine whether or not it should contact the sender of the packet. If so, it
contacts the sender directly by making a TCP connection to the IP address and port
number extracted from the packet. Using RMI, the lookup service sends an object,
called a service registrar, across the network to the originator of the packet. The
purpose of the service registrar object is to facilitate further communication with the
lookup service. By invoking methods on this object, the sender of the announcement
packet can perform join and lookup on the lookup service. In the case of the disk
drive, the lookup service would make a TCP connection to the disk drive and would
send it a service registrar object, through which the disk drive would then register its
persistent storage service via the join process.
Working of Jini
• The join process
• Once a service provider has a service registrar object, the end product of discovery, it is ready to do a join -
- to become part of the federation of services that are registered in the lookup service. To do a join, the
service provider invokes the register() method on the service registrar object, passing as a parameter
an object called a service item, a bundle of objects that describe the service. The register() method
sends a copy of the service item up to the lookup service, where the service item is stored. Once this has
completed, the service provider has finished the join process: its service has become registered in the
lookup service.
• The service item is a container for several objects, including an object called a service object, which clients
can use to interact with the service. The service item can also include any number of attributes, which can
be any object. Some potential attributes are icons, classes that provide GUIs for the service, and objects
that give more information about the service.
• Service objects usually implement one or more interfaces through which clients interact with the service.
For example, a lookup service is a Jini service, and its service object is the service registrar.
The register() method invoked by service providers during join is declared in
the ServiceRegistrar interface, which all service registrar objects implement. Clients and service
providers talk to the lookup service through the service registrar object by invoking methods declared in
the ServiceRegistrar interface. Likewise, a disk drive would provide a service object that implemented
some well-known storage service interface. Clients would look up and interact with the disk drive by this
storage service interface.
Working of Jini
• The lookup process
• Once a service has registered with a lookup service via the join process, that service is available for use by
clients who query that lookup service. To build a distributed system of services that will work together to
perform some task, a client must locate and enlist the help of the individual services. To find a service,
clients query lookup services via a process called lookup.
• To perform a lookup, a client invokes the lookup() method on a service registrar object. (A client, like a
service provider, gets a service registrar through the process of discovery, as described earlier in this
article.) The client passes as an argument to lookup() a service template, an object that serves as
search criteria for the query. The service template can include a reference to an array of Class objects.
These Class objects indicate to the lookup service the Java type (or types) of the service object desired
by the client. The service template can also include a service ID, which uniquely identifies a service, and
attributes, which must exactly match the attributes uploaded by the service provider in the service item.
The service template can also contain wildcards for any of these fields. A wildcard in the service ID field, for
example, will match any service ID. The lookup() method sends the service template to the lookup
service, which performs the query and sends back zero to many matching service objects. The client gets a
reference to the matching service objects as the return value of the lookup() method.
• In the general case, a client looks up a service by Java type, usually an interface. For example, if a client
needed to use a printer, it would compose a service template that included a Class object for a well-known
interface to printer services. All printer services would implement this well-known interface. The lookup
service would return a service object (or objects) that implemented this interface. Attributes can be included
in the service template to narrow the number of matches for such a type-based search. The client would
use the printer service by invoking on the service object methods declared in the well-known printer service
interface.
Service Oriented Architecture
• Service-oriented architecture (SOA) is a method of software development that
uses software components called services to create business applications.
• Each service provides a business capability, and services can also communicate
with each other across platforms and languages.
• Developers use SOA to reuse services in different systems or combine several
independent services to perform complex tasks.
• For example, multiple business processes in an organization require the user
authentication functionality. Instead of rewriting the authentication code for all
business processes, you can create a single authentication service and reuse it for
all applications. Similarly, almost all systems across a healthcare organization,
such as patient management systems and electronic health record (EHR) systems,
need to register patients. These systems can call a single, common service to
perform the patient registration task.
Benefits Of Service-oriented Architecture
• Service-oriented architecture (SOA) has several benefits over the traditional
monolithic architectures in which all processes run as a single unit. Some major
benefits of SOA include the following:
• Faster time to market
• Developers reuse services across different business processes to save time and costs. They
can assemble applications much faster with SOA than by writing code and performing
integrations from scratch.
• Efficient maintenance
• It’s easier to create, update, and debug small services than large code blocks in monolithic
applications. Modifying any service in SOA does not impact the overall functionality of the
business process.
• Greater adaptability
• SOA is more adaptable to advances in technology. You can modernize your applications
efficiently and cost effectively. For example, healthcare organizations can use the
functionality of older electronic health record systems in newer cloud-based applications.
Basic Principles Of Service-oriented
Architecture
• There are no well-defined standard guidelines for implementing service-oriented
architecture (SOA). However, some basic principles are common across all SOA
implementations.
• Interoperability : Each service in SOA includes description documents that specify the
functionality of the service and the related terms and conditions. Any client system can run a
service, regardless of the underlying platform or programming language. For instance, business
processes can use services written in both C# and Python. Since there are no direct interactions,
changes in one service do not affect other components using the service.
• Loose coupling : Services in SOA should be loosely coupled, having as little dependency as
possible on external resources such as data models or information systems. They should also be
stateless without retaining any information from past sessions or transactions. This way, if you
modify a service, it won’t significantly impact the client applications and other services using the
service.
• Abstraction : Clients or service users in SOA need not know the service's code logic or
implementation details. To them, services should appear like a black box. Clients get the required
information about what the service does and how to use it through service contracts and other
service description documents.
• Granularity : Services in SOA should have an appropriate size and scope, ideally packing one
discrete
business function per service. Developers can then use multiple services to create a composite
service for performing complex operations.
Components In Service-oriented Architecture
• There are four main components in service-oriented architecture (SOA).
• Service : Services are the basic building blocks of SOA. They can be private—available only to internal
users of an organization—or public—accessible over the internet to all. Individually, each service has
three main features.
• Service implementation : The service implementation is the code that builds the logic for performing the
specific service function, such as user authentication or bill calculation.
• Service contract : The service contract defines the nature of the service and its associated terms and
conditions, such as the prerequisites for using the service, service cost, and quality of service provided.
• Service interface : In SOA, other services or systems communicate with a service through its service interface.
The interface defines how you can invoke the service to perform activities or exchange data. It reduces
dependencies between services and the service requester. For example, even users with little or no
understanding of the underlying code logic can use a service through its interface.
• Service provider : The service provider creates, maintains, and provides one or more services that
others can use. Organizations can create their own services or purchase them from third-party service
vendors.
• Service consumer : The service consumer requests the service provider to run a specific service. It can
be an entire system, application, or other service. The service contract specifies the rules that the
service provider and consumer must follow when interacting with each other. Service providers and
consumers can belong to different departments, organizations, and even industries.
• Service registry : A service registry, or service repository, is a network-accessible directory of available
services. It stores service description documents from service providers. The description documents
contain information about the service and how to communicate with it. Service consumers can easily
discover the services they need by using the service registry.
Working of Service-oriented Architecture
• In service-oriented architecture (SOA), services function independently and provide functionality
or data exchanges to their consumers. The consumer requests information and sends input data
to the service. The service processes the data, performs the task, and sends back a response. For
example, if an application uses an authorization service, it gives the service the username and
password. The service verifies the username and password and returns an appropriate response.
• Communication protocols
• Services communicate using established rules that determine data transmission over a network.
These rules are called communication protocols. Some standard protocols to implement SOA
include the following:
• Simple Object Access Protocol (SOAP)
• RESTful HTTP
• Apache Thrift
• Apache ActiveMQ
• Java Message Service (JMS)
• User can even use more than one protocol in your SOA implementation.
Limitations In Implementing Service-oriented
Architecture
• Limited scalability
• System scalability is significantly impacted when services share many resources and
need to coordinate to perform their functionality.
• Increasing interdependencies
• Service-oriented architecture (SOA) systems can become more complex over time
and develop several interdependencies between services. They can be hard to
modify or debug if several services are calling each other in a loop. Shared resources,
such as centralized databases, can also slow down the system.
• Single point of failure
• For SOA implementations with an ESB, the ESB creates a single point of failure. It is a
centralized service, which goes against the idea of decentralization that SOA
advocates. Clients and services cannot communicate with each other at all if the ESB
goes down.
The Future of Recent Trends
• A distributed system consists of several computers that communicate over a
network to coordinate the actions and processes of a common application.
• Distributed systems techniques have gained much interest in recent years due to
the proliferation of the Web and other Internet-based systems and services.
• The Future of Recent Trends
• Future in Communication Paradigms
• Future in Software Infrastructures and Middleware for Distributed Systems
• Future in Mobility
• Future in Ubiquitous Computing
• Future in Smart Devices
• Future in Spontaneous Networks
• Future in Smart Identification
The Future of Recent Trends
• Future in Communication Paradigms
• There are many ways that application software components residing on different
machines can communicate with one another over a network. One low-level
technique is to directly use the call interfaces of the network layer, such as the socket
mechanism, together with a custom communication protocol.
• Future in Software Infrastructures and Middleware for Distributed
Systems
• Middleware and software infrastructures for distributed systems (such as DCE,
CORBA or Jini) provide basic communication facilities to application components and
handle issues such as platform heterogeneity that are due to differing hardware
systems, operating systems, or programming languages. Furthermore, they provide a
set of standard services that are typically needed by distributed applications such as
directory service or cryptographic security.
The Future of Recent Trends
• Future in Mobility
• People have an increasing desire for ubiquitous access to information, anywhere,
anyplace, and anytime. For that, they need mobile and portable devices, but also
adequate communication systems and software infrastructures.
• Future in Ubiquitous Computing
• The vision of Ubiquitous Computing is grounded in the firm believe among the
scientific community that Moore's Law (i.e., the observation that the computer
power available on a chip approximately doubles every eighteen months) will hold
for at least another 15 years. This means that in the next few years microprocessors
will become so small and inexpensive that they can be embedded in almost
everything - not only electrical devices, cars, household appliances, toys, and tools,
but also such mundane things like pencils (e.g., to digitize everything we draw) or
clothes. All these devices will be interwoven and connected together by wireless
networks. In fact, communication technology is expected to make further dramatic
improvements, which means that eventually billions of tiny and mobile processors
will occupy the environment and be incorporated into many objects of the physical
world.
The Future of Recent Trends
• Future in Smart Devices
• "Smart device" is a fancy name for a whole range of future devices that come in
various shapes and sizes and are designed for various task-specific purposes. They all
have in common that they are equipped with embedded microprocessors and are
connected (usually by wireless means) to other smart devices or directly to the
Internet. Some of these devices may be equipped with appropriate task-specific
sensors. Others, usually called "information appliances", allow users to gain direct,
simple, and secure access to both relevant information (e.g., daily news and email)
and services. Their user interface is based on speech recognition, gesture
recognition, or some other advanced natural input mode technology that is
appropriate for their purpose, size, and shape. Multimodal human-computer
interaction techniques also help to identify persons and thus to protect the access to
the device. All these devices are so highly optimized to particular tasks that they
blend into the world and require little technical knowledge on the part of their users
- they should be as simple to use as calculators, telephones or toasters.
The Future of Recent Trends
• Future in Spontaneous Networks
• The so-called networked home not only simplifies the installation of security systems
or energy management systems, but adds communications features to arbitrary
home appliances and greatly amplifies their convenience. For that purpose, systems
such as HAVi (Home Audio/Video Interoperability Architecture) are being developed
by major consumer electronic vendors. With such a standardized middleware layer,
interoperability between devices of different vendors is being achieved, which allows
the combination of functions that have previously been separated. It implies a
transition for home electronics products from largely stand-alone single purpose
devices to cooperating elements in a system environment
The Future of Recent Trends
• Future in Smart Identification
• One of the major problems in Ubiquitous Computing is the identification of
objects. For retail-based applications, barcode labels are typically used, which
have a number of drawbacks however (such as the visibility of the barcode
and the fact that it is a read-only item). So-called smart labels or RFID tags
represent a newer and more interesting concept for identifying objects.A
smart label is a small, low-power microchip combined with an antenna,
implanted in a physical object. Each label has a unique serial number and can
contain other programmable information. The information contained in a
label can be transmitted to a nearby reader device by a radio frequency (RF)
signal. Hence, smart labels are contactless, and require neither touch nor line
of sight. In particular, they work through plastic, wood, and other materials