|
UNIT – 5 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Unit-05/Lecture-01 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Distributed Data Base Management System(DDBMS) (2012) A
distributed database (DDB) is a collection of multiple, logically
interrelated databases distributed over a computer network. A distributed
database management system (D–DBMS) is the software that manages the DDB and
provides an access mechanism that makes this distribution transparent to the
users. Distributed
database system (DDBS) = DDB + D–DBMS What is not a DDBS? (i)
A timesharing computer system (ii)
A loosely or tightly coupled multiprocessor system (iii)
A database system which resides at one of the nodes of a network of computers this is
a centralized database on a network
node Implicit
Assumptions Data
stored at a number of sites:-each site logically consists of a single
processor. Processors at different sites are interconnected by a computer
network:-no multiprocessors ,it is parallel database systems.
Distributed database is a database, not a collection of files-data logically
related as exhibited in the users’ access patterns relational data model.
D-DBMS is a full-fledged DBMS-not remote file system, not a TP system’ Advantages of distributed
database: 1) In a distributed
database, data can be stored in different systems like personal computers,
servers, mainframes, etc. 2) A user doesn’t know
where the data is located physically. Database presents the data to the user
as if it were located locally. 3) Database can be
accessed over different networks. 4) Data can be joined
and updated from different tables which are located on different machines. 5) Even if a system
fails the integrity of the distributed database is maintained. 6) A distributed
database is secure. Disadvantages of distributed database: 1) Since the data is
accessed from a remote system, performance is reduced. 2) Static SQL cannot be
used. 3) Network traffic is
increased in a distributed database. 4) Database optimization
is difficult in a distributed database. 5) Different data
formats are used in different systems. 6) Different DBMS
products are used in different systems which increases in complexity of the
system. 7) Managing system
catalogue is a difficult task. 8) While recovering a
failed system, the DBMS has to make sure that the recovered system is
consistent with other systems. 9) Managing distributed
deadlock is a difficult task. ……………Reference{ https://cs.uwaterloo.ca} Video link {https://www.youtube.com/watch?v=qMjCliHkdZk}
Types
of Distributed Database(Dec2013) DDBMS may be classified as homogeneous or heterogeneous: Homogeneous A homogeneous distributed database environment is depicted in
Figure 5.1.
FIGURE: Homogeneous distributed
database environment This environment is typically defined by the following
characteristics (related to the non autonomous category described
previously): (i)
Data are distributed
across all the nodes. (ii)
The same DBMS is
used at each location. (iii)
All data are managed
by the distributed DBMS (so there are no exclusively local data)
In Homogeneous: The same DBMS is used at each node. A.
Autonomous :Each
DBMS works independently, passing messages back and forth to share data
updates. B.
Non autonomous: A
central, or master, DBMS coordinates database access and updates across the
nodes. Heterogeneous
In Heterogeneous: (i)
All users access the database
through one global schema or databasedefinition. (ii)
The global schema is simply the
union of all the local database schemas. It is
difficult in most organizations to force a homogeneous environment, yet
heterogeneous environments are much more difficult to manage. A
heterogeneous environment will be defined by the following characteristics
(as depicted in Figure) (i)
Data are distributed across all
the nodes. (ii)
Different DBMSs may be used at
each node. (iii)
Some users require only local access to
databases, which can be accomplished by using only the local DBMS and schema. (iv)
A global schema exists, which
allows local users to access remote data. Heterogeneous Database: Potentially
different DBMSs are used at each node. A. Systems Supports some or all of the
functionality of one logical database. 1.
Full DBMS functionality Supports all of the functionality of a distributed
database, 2.
Partial-multidatabase Supports some features of a distributed database, a Federated
Supports local databases for unique data requests. (i.) Loose
integration Many schemas exist, for each local database, and each local DBMS
must communicate with all local schemas. (ii) Tight
integration One global schema exists that defines all the data across all
local databases. b. Un
federated Requires all access to go through a central coordinating module. B. Gateways
Simple paths are created to other databases, without the benefits of one
logical database ……………Reference { }
Unit-05/Lecture-03 Distributed Multimedia (Dec 2012) Definition: Distributed
multimedia systems consist of multimedia databases, proxy and information
servers, and clients, and are intended to for the distribution of multimedia
content over the networks. Multimedia applications generate and consume continuous
streams of data in real time. They
contain large quantities of audio, video
and other time-based data elements, and the timely processing and delivery of the individual data elements is
essential Modern computers can handle streams of continuous, time-based data
such as digital audio and video. This capability has led to the development
of distributed multimedia applications such as networked video libraries,
Internet telephony and video conferencing. Such applications are viable with
current general-purpose networks and systems, although the quality of the
resulting audio and video is often less than satisfactory. More demanding
applications such as large-scale video conferencing, digital TV production,
interactive TV and video surveillance systems are beyond the capabilities of
current networking and distributed system technologies. Multimedia
applications demand the timely delivery of streams of multimedia data to end
users. Audio and video streams are generated and consumed in real time, and
the timely delivery of the individual elements (audio samples, video frames)
is essential to the integrity of the application. In short, multimedia systems are
real-time systems: they must perform tasks and deliver results according to a
schedule that is externally determined. The degree to which this is achieved
by the underlying system is known as the quality of service(QoS)
enjoyed by an application. Architecture A
distributed multimedia system consists of three different basic components: An
Information server, a wide area network and a multimedia client on the user
site. The user interface or the multimedia client deals with the issues
related to presentation and manipulation of multimedia objects and the
interaction with the user. The network provides the communication mechanism
between the user and the server.
The server is responsible for managing multimedia databases and also composing general multimedia
objects for the user. The composition of the object is a complex process of
integrating and synchronizing multimedia data for transport, display and manipulation. The system usually consists
of multiple users, servers and
networks as shown below Figure.:Architecture of DMS Characteristics Of Multimedia Data (Dec
2013) ·
We have referred to video and audio data as continuous and time-based.
How can we define these characteristics more precisely? The term ‘continuous’
refers to the user’s view of the data. Internally, continuous media are
represented as sequences of discrete values that replace each other over
time. For example, the value of an image array is replaced 25 times per
second to give the impression of a TV-quality view of a moving scene; a sound
amplitude value is replaced 8000 times per second to convey telephone-quality
speech. ·
Multimedia streams are said to be time-based(or isochronous) because
timed data elements in audio and video streams define the semantics or
‘content’ of the stream. The times at which the values are played or recorded
affect the validity of the data. Hence systems that support multimedia
applications need to preserve the timing when they handle continuous data. ·
Multimedia streams are often bulky. Hence systems that support
multimediaapplications need to move data with greater throughput than
conventional systems. Figure -a ,shows some typical data rates and
frame/sample frequencies We note that the resource bandwidth requirements for
some are very large. This is especially so for video of reasonable quality.
Figure -a ·
For example, an uncompressed standard TV video stream requires more
than 120 Mbps, which exceeds the capacity of a 100-Mbps Ethernet network. A
program that copies or applies a simple data transformation to each frame of
a standard TV video streamrequires less than 10% of the CPU capacity of a PC.
·
The figures for high-definition television streams are higher, and we
should note that in many applications, such as video conferencing, there is a
need to handle multiple video and audio streams concurrently. The use of
compressed representations to overcome these problems is therefore essential,
although transformations such as video mixing and editing are difficult to
accomplish with compressed streams ·
Although the use of compressed video and audio data reduces bandwidth
requirements in communication networks it imposes substantial additional
loads on processing resources at the source and destination. This processing
has often been supplied through the use of special-purpose hardware to
process and despatch video and audio information – the video and audio coders/decoders
(Codecs) found on video cards manufactured for personal computers. ·
But increasing central processor power of personal computers and
multiprocessor architectures are likely to enable them to perform much of
this work in software using software coding and decoding filters. This
approach offers greater flexibility with better support for
application-specific data formats, special-purpose application logic and the
simultaneous handling of multiple media streams. ……………Reference { george-coulouris-distributed-systems-concepts-and-design,886}
Unit-05/Lecture-04 Quality of
service management ·
When multimedia applications run in networks of personal computers
they compete for resources at the workstations running the applications
(processor cycles, bus cycles,buffer capacity) and in the networks (physical
transmission links, switches, gateways). ·
Workstations and networks may have to support several multimedia and
conventional applications. There is competition between the multimedia and
conventional applications, between different multimedia applications and even
between the media streams within individual applications. ·
The concurrent use of physical resources for a variety of tasks has
long been possible with multi-tasking operating systems and shared networks.
In multi-tasking operating systems the central processor is allocated to
individual tasks (or processes) in a round-robin or other scheduling scheme
that shares the processing resources on a best-efforts basis amongst all of
the tasks currently competing for the central processor. ·
Networks are designed to enable messages from different sources to be
interleaved allowing many virtual communication channels to exist on the same
physical channels. The predominant local-area network technology, Ethernet,
managesa shared transmission medium in a best-efforts manner. ·
Any node may use the medium when it is quiet. But packet collisions
can occur and when they do sending nodes wait for random backoff periods in
order to prevent repeated collisions. Collisions are likelyto occur when the
network is heavily loaded and this scheme cannot provide anyguarantees
regarding the bandwidth or latency in such situations ·
The key feature of these resource allocation schemes is that they
handle increases in demand by spreading the available resources more thinly
between the competing tasks. Round-robin and other best-efforts methods for
sharing processor cycles and network bandwidth cannot meet the needs of
multimedia applications. ·
As we have seen, the timely processing and transmission of multimedia
streams is crucial for them. Late delivery is valueless. In order to achieve
timely delivery, applications need guarantees that the necessary resources
will be allocated and scheduled at the required times. ·
The management and allocation of resources
to provide such guarantees is referred to as quality of service management. . Figure -b Typical infrastructure components for multimedia applications ·
Figure b,
shows the infrastructure components for a simple multimedia conferencing application running on
two personal computers, using software data compression and format
conversion. The white boxes represent software components whose resource
requirements may affect the quality of service of the application. ·
The figure shows the most commonly-used abstract architecture for
multimedia software, in which continuously flowing streams of media data
elements (video frames,audio samples) are processed by a collection of
processes and transferred between theprocesses by inter-process connections. ·
The processes produce, transform and consume continuous streams of
multimedia data. The connections link the processes in a sequence from a
source of media elements to a target at which it is rendered or consumed. The
connections between the processes may be implemented by networked connections
or by in-memory transfers when processes reside on the same machine. ·
For the elements of multimedia data to arrive at their target on time,
each process must be allocated adequate CPU time, memory capacity and network
bandwidth to perform its designated task and must be scheduled to use the
resources sufficiently frequently to enable it to deliver the data elements
in its stream to the next process on time
Figure –c QoS specs for components of the
application In Figure –c, we set out
resource requirements for the main software components and network connections
in Figure –b. Figure –d The QoS manager’s task Figure -d shows the QoS
manager’s responsibilities in the form of a flowchart. In the next two
sub-sections we describe the QoS manager’s two main sub-tasks: •Quality of service negotiation : The application indicates its resource requirements to the QoS
manager. The QoS manager evaluates the feasibility of meeting the requirements
against a database of the available resources and current resource commitments
and gives a positive or negative response. If it is negative, the application
may be reconfigured to use reduced resources and the process is repeated. •Admission control: If the
result of the resource evaluation is positive, the requested resources are
reserved and the application is given a Resource Contract, stating the resources
that have been reserved. The contract includes a time limit.The application
is then free to run. If it changes its resource requirements it must notify
the QoS Manager. If the requirements decrease, the resources released are returned
to the database as available resources. If they increase, a new round of negotiation
and admission control is initiated ……………Reference { george-coulouris-distributed-systems-concepts-and-design,887} Unit-05
/Lecture-05
Case
Study of Distributed System:- Amoeba, Mach, Chorus Amoeba The
Amoeba operating system is designed to run on multiple machines across a
network which appears to each user as a single shared machine. It is a
heterogeneous distributed operating system designed for general-purpose
computing. “It is designed to take a collection of machines and make them act
together as a single integrated system.”
Details about where processes are run or files are being stored are
hidden to the user. Amoeba can be used both as a distributed system for
multiple users with multiple tasks, or a parallel system for a single
difficult job. Background There
was an explosion in personal computing in the 1980's when computers became
affordable enough for each user to have a workstation. Around this time, a
group at the Vrije Universiteit (VU) in Amsterdam started working on the
problem of using multiple individual user systems in distributed and parallel
ways. System Design The
design goals for the Amoeba operating system included distribution,
parallelism, transparency, and performance: ·
Distribution – Amoeba is a
heterogeneous system which can be built on a LAN. ·
Parallelism – Amoeba can use multiple
processors for a single job to decrease the total run time for the job. ·
Transparency – Amoeba hides details
about how the resources of the various machines are handled from the user. ·
Performance – Amoeba uses an optimized
communication system to reduce the overhead associated with distributed and
parallel computing. Amoeba
also uses a microkernel architecture in which a copy runs on each node in the
system. This kernel supports only the basics needed locally for that system
such as minimal process and communication primitives, memory management, and
raw device I/O. Server processes which run on top of the microkernel are
usually in user space. The
main communication mechanism for Amoeba is remote procedure call (RPC). This
is also hidden from the user in the Amoeba Interface Language (AIL) which
provides functions and procedures that handle the details of communication. Amoeba implements a universell distributed Client-Server-Modell. In
fact, basically the whole system needs only three Functions to do all the
work: The transaction call from the Client, and the GetRequest and PutReply
functions on the Server side. 1.
Workstations 2.
Pool Processors 3.
Specialized Servers (File
server...) 4.
Gateways
File system Amoeba
has dedicated file servers called Bullet servers. These servers store only
the file data and not the names or hierarchy of the file system. “When a user
program needs a file, it will request that the Bullet server send it the
entire file in a single RPC.”This means that a file server must have at least
16 MB of RAM, and the amount of physical memory limits the maximum file size.
Directories and file names are handled by separate directory servers. TCP/IP Amoeba
doesn't use TCP/IP for it's internal communication. However, an Amoeba system
can contain a special server to provide TCP/IP communication to other systems. “Amoeba is available for free to universities and other educational institutions and for special commercial prices and conditions to corporate, government, and other users.” …….. Reference{http://www.cs.vu.nl/pub/amoeba/Intro.pdf,P.K Sinha,643}
Unit-04/Lecture-06
Mach ·
The Mach project [Acetta et al. 1986, Loepere 1991, Boykin et al.
1993] was based at Carnegie-Mellon University in the USA until 1994. Its
development into a real-time kernel continued there [Lee et al. 1996], and
groups at the University of Utah and the Open Software Foundation continued
its development. ·
The Mach kernel was developed to provide direct compatibility with BSD
UNIX. It was designed to provide advanced kernel facilities that would
complement those of UNIX and allow a UNIX implementation to be spread across
a network of multiprocessor and single-processor computers ·
Version 3.0 Mach is a basis for building user-level emulations of
operating systems, database systems, language run-time systems and other
items of system software that we call subsystems Figure-e Mach
tasks, threads and communication Design goals and chief design
features : The main Mach design goals and features are
as follows: ·
Multiprocessor operation:Mach was designed to execute on a shared
memory multiprocessor so that both kernel threads and user-mode threads could
be executed by any processor. Mach provides a multi-threaded model of user
processes, with execution environments called tasksThreads are pre-emptively
scheduled, whether they belong to the same tasks or to different tasks, to
allow for parallel execution on a shared-memory multiprocessor. ·
Transparent extension to network operation:In order to allow for distributed programs
thatextend transparently between uniprocessors and multiprocessors across a
network, Mach has adopted a location-independent communication model
involving ports as destinations. The Mach kernel, however, is designed to be
100% unaware of networks. The Mach design relies totally on user-level
network server processes to ferry messages transparently across the network
(Figure -e). ·
User-level servers:Mach implements an object-based model in
which resources are managedeither by the kernel or by dynamically loaded
servers. Originally, only user-level servers were allowed but later Mach was
adapted to accommodate servers within the kernel’s address space.A primary
aim was for most UNIX facilities to be implemented at user level, while
providing binary compatibility with existing UNIX. With the exception of some
kernel-managed resources, resources are accessed uniformly by message
passing, however they are managed. To every resource, there corresponds a
port managed by a server. ·
Operating system emulation:To support the binary-level emulation of
UNIX and other operating systems, Mach allows for the transparent redirection
of operating system calls to emulation library calls and thence to user-level
operating system servers – a technique known as trampolining. It also includes a facility
that allows exceptions such as address space violations arising in
application tasks to be handled by servers. ·
Flexible virtual memory implementation:Much effort was put into providing virtual
memory enhancements that would equip Mach for UNIX emulation and for
supporting other subsystems. This included taking a flexible approach to the
layout of a process’s address space. Mach supports a large, sparse process
address space, potentially containing many regions. Both messages and open
files, for example, can appear as virtual memory regions. Regions can be private
to a task, shared between tasks or copied from regions in other tasks. The
design includes the use of memory mapping techniques, notably copy-on-write,
to avoid copying data when, for example, messages are passed between tasks.
Finally, Mach was designed to allow servers, rather than the kernel itself,
to implement backing storage for virtual memory pages. Regions can be mapped
to data managed by servers called external pagers ·
Portability:Mach was designed to be portable to a variety of hardware platforms.
For this reason, machine-dependent code was isolated as far as possible. In
particular, the virtual memory code was divided between machine-independent
and machine-dependent parts Communication
model Mach provides a single
system call for message passing: mach_msg
Figure -f Messages: A message consists of a
fixed-size header followed by a variable-length list of data items
(Figure-f). The fixed-size header
contains: ·
The destination port: For simplicity, this is part of the message
rather than being specified as a separate parameter to the mach_msg system
call. It is specified by the local identifier of the appropriate send rights. ·
A reply port: If a reply is required, then send rights to a local port
(that is, one for which the sending thread has receive rights) are enclosed
in the message for this purpose. ·
An operation identifier : This identifies an operation (procedure) in
the service interface and is meaningful only to applications ·
Extra data size : Following the header (that is, contiguous with it)
there is, in general, a variable-sized list of typed items. There is no
length limit to this, except the number of bitsin this field and the total
address space size. ·
Each item in the list after the message header is one of the following
(which can occur in any order in the message): Typed message data:
individual, in-line type-tagged data items; Port rights: referred to
by their local identifiers; Pointers to out-of-line
data: data held in a separate non-contiguous block of memory. Ports: A Mach port has a message queue whose size
can be set dynamically by the task with receive rights. Mach_msg: The Mach_msgsystem call provides for both asynchronous message passing
and request-reply-style interactions, which makes it extremely complicated.
We shall give only an overview of itssemantics. The complete call is as
follows: mach_msg(msg_header, option, snd_siz, rcv_siz, rcv_name, timeout,
notify) msg_header points to a common message header for the sent and received
messages, option specifies send, receive or both, snd_siz and rcv_siz give
the sizes of the sent and received message buffers, rcv_namespecifies the
port or port set receive rights (if a message is received), timeout sets a
limit to the total time to send and/or receive a message, notify supplies
port rights which the kernel is to use to send notification messages under
exceptional conditions. ·
Mach_msg either sends a message, receives a message, or both. It is a
single system call that clients use to send a request message and receive a
reply, and servers use to reply to the last client and receive the next
request message. Another benefit of using a combined send/receive call is
that in the case of a client and server executing at the same computer the
implementation can employ an optimization called handoff scheduling. This is
where a task about to block after sending a message to another task ‘donates’
the rest of its timeslice to the other task’s thread. This is cheaper than
going through the queue of RUNNABLE threads to select the next thread to run. ·
Messages sent by the same thread are delivered in sending order, and
message delivery is reliable. At least, this is guaranteed where messages are
sent between tasks hosted by a common kernel – even in the face of lack of
buffer space. When messages are transmitted across a network to a
failure-independent computer, at-most-once delivery semantics are provided
…….. Reference{http://www.cdk5.net,PK Sinha ,674 }
Unit-04/Lecture-07
Chorus Chorus OS Chorus
is an operating system for embedded systems. An embedded system is a
specialized system that is part of a larger system or machine. Chorus is a
real-time OS (RTOS) which means that it responds immediately to input and can
be used in real-time applications to solve real-time problems. At its
heart is the Chorus nucleus (microkernel). A microkernel is an OS with only
the essential services such as interprocess communication, short-term
scheduling, and memory management. Chorus implements these simple tools and
makes them distributed on the lowest level. Chorus
is designed for reliability, availability, and scalability for critical
telecommunications applications. Background Chorus started in 1980 as a research
project at the French research institute INRIA. It started with version 0
which implemented structured processes called “actors.” In 1982, version 1
continued with multi-processor research and included structured messages and
support for fault tolerance. Version 2 came out in 1984 and was source
compatible with UNIX, meaning that UNIX programs could be recompiled and run
on Chorus. In 1987, with version 3, Chorus went commercial, becoming Chorus Systems Inc. Furthermore, version 3
implemented RPC as the communication model. Design goals and chief
design features: Chorus has the following design goals in common with Mach •microkernel support for open system services, accessed by message
passing; •support for binary-level operating system emulation (in particular
the emulation of UNIX) and other subsystems; •transparent extensibility of kernel facilities to network operation; •flexible virtual memory implementation. • portability (the Chorus
kernel is written in C++ and designed to be modular and split into
machine-dependent and machine-independent parts); •exploitation of shared
memory multiprocessors.
Chorus also has the following goals and features: Dynamically loadable servers: Chorus aims to achieve the same degree of modularity and openness as
does Mach. Chorus supports dynamically loadable servers which may execute
either at user-level or within the kernel address space. Enhancement of UNIX: The Chorus design anticipates that users of the UNIX emulation might
want to use enhanced facilities provided by the underlying kernel from within
UNIX processes, such as multiple threads and the ability to create a new
process at a remote computer. Support for server groups and server reconfiguration: Chorus provides support for server groups
in the form of group addressing modes for sending messages, including
multicast. Port migration can be used to transfer management of a resource or
collection of resources dynamically between servers, and is similar to the
transfer of port receive rights in Mach. Distributed memory multiprocessor operation: Chorus has been implemented on several
distributed memory multiprocessors. Processors used in embedded
multiprocessor systemsmay have relatively primitive hardware support for
memory management. This has constrained the provision of features that assume
the existence of sophisticated MMU hardware. Real-time operation : The Chorus design aims to support real-time subsystems on the
kernel.To this end, Chorus provides for flexible allocation of thread
priorities and allows forcustomized thread scheduling policies; threads
executing within the kernel can be scheduled pre-emptively Chorus Microkernel The
Chorus microkernel (which they like to call the “nucleus”) has 4 major parts.
The first part, the supervisor, handles hardware interrupts, traps, and
exceptions. This portion must be rewritten when it is ported to a new system.
The second part, the real-time executive, manages the processes, threads, and
scheduling, along with the synchronization between threads. The virtual
memory manager takes care of the low-level part of the paging system. The
inter-process communication manager handles the UI’s (unique identifiers),
ports, and sending messages in a transparent way. The
Chorus microkernel has low-level transparent connectivity services that let
you distribute functions across multiple PCs. When one fails, you can
automatically off-load to another. The size of the Chorus microkernel is
about 50 to 60 Kb. Processes There
are 3 kinds of processes which interact with each other and the nucleus to
get jobs done. Starting with the lowest level, the processes are kernel,
system, and user. Kernel processes reside in kernel space along with the
nucleus. System and user processes reside in user space. (i)
Kernel processes are trusted and
privileged, able to make demands on the nucleus and implement their own
hardware functions. Kernel processes complete the necessary requirements
for a basic operating system, and provide things such as file managers,
stream and sock managers, device drivers, etc. However, these processes are
only loaded as needed and can be removed or added during system execution.
The relationship between kernel processes and the nucleus provide a way to
extend and configure the functionality of the OS. (ii)
System processes are trusted,
able to send requests to kernel processes and to the nucleus itself. A
subsystem consists of a collection of system processes that work together,
eg. the UNIX subsystem known as MiX allows binary compatibility with UNIX. (iii)
User processes are neither trusted
or privileged. They may only ask something of the nucleus or kernel through a
subsystem. No direct calls are allowed. Real-time
processes can run as system processes to reduce overhead Comparisons and Conclusions Amoeba
was designed to be used on multiple CPU's connected by a LAN, whereas Chorus
was designed to provide distributed services and architecture for embedded
systems. Chorus started out far from UNIX, but has increasingly become closer
and closer to UNIX. While Amoeba is designed to abstract or hide the multiple
machines from users, Chorus was designed with the idea that users would not
only be logging into a particular machine but would be doing most of their
work on that machine.
Fig:A
compare is on of A moeba, Mach, and Chorus …….. Reference{http://www.cdk5.net,PK Sinha ,696 }
Unit-04/Lecture-08 What is a middleware? What do we expect it
to solve? Illustrate with CORBA? (2014) Middleware is
computer software that
provides services to software applications beyond those available from the operating
system.
It can be described as "software glue".[1] Middleware
makes it easier for software developers to perform communication and input/output, so they
can focus on the specific purpose of their application. Middleware is the
software that connects software components or enterprise applications.
Middleware is the software layer that lies between the operating system and
the applications on each side of a distributed computer network. Typically,
it supports complex, distributed business software applications. Middleware
includes Web servers, application servers, content management systems, and
similar tools that support application development and delivery. Among the middleware supports for distributed objects, the Object
Management Group (OMG) Common Object Request Broker Architecture (CORBA) is certainly the
most widespread, complex and mature infrastructure,. CORBA is a middleware that permits a very rich variety of
coordination modalities between its components. The architecture is based
on the concept of a common software bus allowing for distributed object interoperability
and providing a wide set of bus-related services to interacting objects. The
main aim is to release application developers from all the duties that stem
from the possible heterogeneity and distribution of C/S components: CORBA client objects have
no visibility of the location of the CORBA server objects they collaborate
with, and their interaction is completely independent of both their
implementation language and the platform where they are running. The most
notable consideration in this context is that CORBA, apart from the variety
of available policies for communication and coordination between components,
has been designed from the beginning as a complex and layered architecture of
facilities and services to support the implementation of distributed C/S applications …….. Reference{http://en.wikipedia.org} Concurrency control in distributed
databases ?(Dec -2014) Concurrency Control: In
distributed database systems database is typically used by many users. These
systems usually allow multiple transactions to run concurrently i.e. at the
same time. Concurrency control is the activity of coordinating concurrent
accesses to a database in a multiuser database management system (DBMS).
Concurrency control permits users to access a database in a multi-programmed
fashion while preserving the illusion that each user is executing alone on a
dedicated system. The main technical difficulty in attaining this goal is to
prevent database updates performed by one user from interfering with database
retrievals and updates performed by another.When the transactions are
updating data concurrently, it may lead to several problems with the
consistency of the data. …….. Reference{. www.ijarcsse.com/docs/papers} Top-Down and bottom-up approach to the
design of data distribution Top-down approach : Top-down design process is mostly used in designing system from
scratch. Figure illustrates the process of top-down design. The process starts from a requirement analysis
phase including analyzing of the company situation, defining problems and
constraints, defining objectives, and designing scope and boundaries. The
next two activities are conceptual design and view design. Focus on the data requirements, the conceptual design deals with
entity relationship modeling and normalization . It creates the abstract data
structure to represent the real world items. The view design defines the user
interfaces. The conceptual schema is a virtual view of all databases taken
together in a distributed database environment. It should cover the entity
and relationship requirement for all user views. Furthermore, the conceptual model should support existing applications
as well as future applications. The definition of the global conceptual
schema (GCS) comes from the conceptual design. The next step is distribution
design . The global conceptual schema and the access information collected
from the view design activity are inputs of this step. By fragmenting and
distributing entities over the system, this step designs the local conceptual
schemas. Therefore, this step can be further divided into two steps:
fragmentation and allocation. Distribution design also includes the selection
of DBMS software in each site. The mapping of the local conceptual schemas to
the physical storage devices is accomplished through the physical design
activity. Throughout the design and development of the distributed database
system, constant monitoring and periodic adjustment and tuning are also
critical activities in order to achieve successful database implementation
and suitable user interfaces. …….. Reference{. http://www.ijeset.com/media/11N5-IJESET0202505.pdf}
Bottom-up approach Bottom-upapproach is
suitable when the objective of the design is to integrate existing database systems. The bottom-up design starts from the individual local conceptual
schemas and the objective of the process is integrating local schemas into
the global conceptual schema. One of the most important aspects of design
strategy is to determine how to integrate multiple database system together.
Implementation alternatives are classified according to the autonomy,
distribution, and heterogeneity of the local systems. Autonomy indicates the independency of individual DBMS. In the
autonomous system, the individual DBMS are able to perform local operations
independently and have no reliance on centralized service or control. The
consistency of the whole system should not be affected by the behavior of the
individual DBMS . Three possible degrees of autonomy are tight integration,
semiautonomous system, and total isolation. In a system which is tightly
integrated, although information is stored in multiple databases, users only
see a single image of the entire system [3]. One of the DBMS controls the
processing of the user request. The DBMS in semiautonomous system can operate
separately and they are also willing to share their local data. In total
isolated systems, individual DBMS do not know the existence of other DBMS. The physical distribution
of data over multiple sites is another characteristic of distributed
databases. Distributed system can be classified as client/server distribution
or peer-to-distribution based on how the data are distributed and how to
manage them. Heterogeneous DDBMS integrate multiple independent databases
into a single distributed database system and provide transparency of the
heterogeneity. Individual DBMS can implement different data model, use
different query language and transaction management protocols
. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
