INTERSYSTEMS COMMUNICATION

UNIT 1
DESTRIBUTED COMPUTING
INFRASTRUCTURE

08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 1

 What is distributed computing?
 Distributing Computing is a type of computing in which different
components and objects comprising an application can be located on
different computers connected to a network.

 Figure 1.1 shows a distributed computing model that provides an

infrastructure enabling invocations of object functions located anywhere
on the network.

 The objects are transparent to the application and provide processing

power as if they were local to the application calling them.

08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 2

Internet-based distributed computing model

08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 3

Importance of distributed computing

 Higher performance- Applications can execute in parallel and distribute

the load across multiple servers.
 Collaboration- Multiple applications can be connected through standard
distributed computing mechanisms.
 Higher reliability and availability- Applications or servers can be
 clustered in multiple machines.
 Scalability -This can be achieved by deploying these reusable distributed
 components on powerful servers.
 Extensibility -This can be achieved through dynamic (re)configuration
 of applications that are distributed across the network.
 Higher productivity and lower development cycle time - By breaking
up large problems into smaller ones, these individual components
can be developed by smaller development teams in isolation.

Mr K Zvarevashe, Lecturer, Harare Institute of Technology, Zimbabwe 4

Importance of distributed computing…

 Reuse - The distributed components may perform various services

that can potentially be used by multiple client applications. It saves
repetitive development effort and improves interoperability between
components.
 Reduced cost - Because this model provides a lot of reuse of once
developed components that are accessible over the network, significant
cost reductions can be achieved.

08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 5

Core distributed computing technologies – client/server

 In a two-tier architecture model, the first (upper) tier handles

the presentation and business logic of the user application
(client), and the second/lower tier handles the application
organization and its data storage (server).

 This approach is commonly called client-server applications

architecture.

 Generally, the server in a client/server application model is a

database server that is mainly responsible for the
organization and retrieval of data.

08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 6

client/server…

 The application client in this model handles most of the business

processing and provides the graphical user interface of the application.

 It is a very popular design in business applications where the user

interface and business logic are tightly coupled with a database server for
handling data retrieval and processing.

 For example, the client-server model has been widely used in enterprise
resource planning (ERP), billing, and Inventory application systems
where a number of client business applications residing in multiple
desktop systems interact with a central database server.

Mr K Zvarevashe, Lecturer, Harare Institute of Technology, Zimbabwe 7

client/server…

Mr K Zvarevashe, Lecturer, Harare Institute of Technology, Zimbabwe 8

limitations of the client-server application model

 Complex business processing at the client side demands robust client

systems.

 Security is more difficult to implement because the algorithms and logic

reside on the client side making it more vulnerable to hacking.

 Increased network bandwidth is needed to accommodate many calls to

the server, which can impose scalability restrictions.

 Maintenance and upgrades of client applications are extremely difficult

because each client has to be maintained separately.

 Client-server architecture suits mostly database-oriented standalone

applications and does not target robust reusable component oriented
applications.

Mr K Zvarevashe, Lecturer, Harare Institute of Technology, Zimbabwe 9

CORBA

 The Common Object Request Broker Architecture (CORBA) is an industry

wide, open standard initiative, developed by the Object Management
Group (OMG) for enabling distributed computing that supports a wide
range of application environments.
 CORBA differs from the traditional client/server model because it
provides an object-oriented solution that does not enforce any
proprietary protocols or any particular programming language,
operating system, or hardware platform.
 By adopting CORBA, the applications can reside and run on any
hardware platform located anywhere on the network, and can be written
in any language that has mappings to a neutral interface definition
called the Interface Definition Language (IDL).

Mr K Zvarevashe, Lecturer, Harare Institute of Technology, Zimbabwe 10

CORBA…

 An IDL is a specific interface language designed to expose

the services (methods/functions) of a CORBA remote object.

 CORBA also defines a collection of system-level services for

handling low-level application services like life-cycle,
persistence, transaction, naming, security, and so forth.

 Initially, CORBA 1.1 was focused on creating component

level, portable object applications without interoperability.

 The introduction of CORBA 2.0 added interoperability

between different ORB vendors by implementing an Internet
Inter-ORB Protocol (IIOP).
Mr K Zvarevashe, Lecturer, Harare Institute of Technology, Zimbabwe 11
limitations of the client-server application model

 Complex business processing at the client side demands robust client

systems.

 Security is more difficult to implement because the algorithms and logic

reside on the client side making it more vulnerable to hacking.

 Increased network bandwidth is needed to accommodate many calls to

the server, which can impose scalability restrictions.

 Maintenance and upgrades of client applications are extremely difficult

because each client has to be maintained separately.

 Client-server architecture suits mostly database-oriented standalone

applications and does not target robust reusable component oriented
applications.

Mr K Zvarevashe, Lecturer, Harare Institute of Technology, Zimbabwe 12

CORBA

 The Common Object Request Broker Architecture (CORBA) is an industry

wide, open standard initiative, developed by the Object Management
Group (OMG) for enabling distributed computing that supports a wide
range of application environments.
 CORBA differs from the traditional client/server model because it
provides an object-oriented solution that does not enforce any
proprietary protocols or any particular programming language,
operating system, or hardware platform Increased network
bandwidth is needed to accommodate many calls to the server, which
can impose scalability restrictions.
 By adopting CORBA, the applications can reside and run on any
hardware platform located anywhere on the network, and can be written
in any language that has mappings to a neutral interface definition called
the Interface Definition Language (IDL).
 An IDL is a specific interface language designed to expose the services
(methods/functions) of a CORBA remote object.
Mr K Zvarevashe, Lecturer, Harare Institute of Technology, Zimbabwe 13
What is the purpose / goals of CORBA?

 Enable the building of plug and play

component software environment
 Enable the development of portable, object
oriented, interoperable code that is
hardware, operating system, network, and
programming language independent
How to meet goals?

 Interface Definition Language (IDL)

 Object Request Broker (ORB)
Interface Definition Language (IDL)

 Language Independence
 Defines Object Interfaces
 Hides underlying object implementation
 Language mappings exist for C, C++, Java,
Cobol, Smalltalk, and Ada
Interface Definition Language (IDL)

module <identifier> Defines a container

{
interface <identifier> [:inheritance]
(namespace)
{
<type declarations>;
<constant declarations>; Defines a
<exception declarations>; CORBA object
<attribute declarations>;

[<op_type>] <identifier>(<parameters>)
[raises exception][context];
}
}
Defines a
method
IDL Compiler

IDL
Definitions 1. Define objects using
IDL
2. Run IDL file through
IDL compiler
3. Compiler uses language
IDL mappings to generate
Compiler programming language
specific stubs and
skeletons

Stubs Skeletons
Object Request Broker (ORB)

 What is it?
 Architecture
 Request Handling
 Scenario
 CORBA Services
 CORBA Facilities
What is it?

 Implementation of CORBA specification

 Middleware product
 Conceptual Software Bus
 Hides location and
implementation details Application
about objects
Middleware
OS Drivers

Hardware
Client / Object Interaction

Client Obj Impl Client Obj Impl

IDL IDL IDL IDL

ORB ORB
TCP/IP

TCP/IP
ATM

ATM
IPX

IPX
OSI

Network OSI
ORB Architecture

Interface IDL Implementation

Repository Compiler Repository

Client OBJ Object (servant)

Ref

IDL
DSI
IDL ORB Skeleton
DII
Stub Interface
Object Adapter

GIOP/IOOP ORB Core

Interface Repository

Interface
Repository

• Database of object definitions

• Contains metadata about each object
• Allows for introspection
• Allows clients to discover interfaces at run-time
• Used in support of dynamic invocations
Object Adapter
IDL Compiler

IDL
Compiler

• Compiles IDL definition into stubs and

skeletons
• Uses OMG specified language mappings
to translate IDL into a language specific
implementation

Object Adapter
Implementation Repository

Implementation
Repository

• Contains information that allows the ORB

to locate and activate object
implementations
• Provides information about the classes a
server supports, the objects that are
instantiated, and their IDs
Object Adapter
ORB Core

• Provides mechanism for transparently

communicating client requests to target
object implementations
• Makes client requests appear to be local
procedure calls
• GIOP – General Inter-ORB Protocol
• IIOP – Internet Inter-ORB Protocol

Object Adapter

GIOP/IOOP ORB Core

ORB Interface

Client Object (servant)

• Provides helper functions

• Converting object
ORB
references to strings
Interface
Object Adapter
• Creating argument
lists for requests made
through DII
IDL Stub

 Static invocation
interface (SII)
Client  Marshals
application data
into a common
packet-level
IDL representation
Stub  Network byte order
(little-endian or big-
endian)
IDL Skeleton

• Demarshals the
packet-level
representation back Object (servant)
into typed data that is
meaningful to an
application IDL
– Network byte order Skeleton
(little-endian or big-
endian)
– Size of data types
Dynamic Invocation Interface

• Dynamically issue requests to objects

without requiring IDL stubs to be
linked in
Client • Clients discover interfaces at run-
time and learn how to call them
Steps:
1. Obtain interface name
2. Obtain method description (from
DII interface repository)
3. Create argumentObject
list Adapter
4. Create request
5. Invoke request
Dynamic Skeleton Interface

• Server side analogue to DII

• Allows an ORB to deliver
Object (servant)
requests to an object
implementation that does
not have compile-time
knowledge of the type of DSI
object it is implementing
Object Adapter
 Object Adapter

• Accept requests for service on behalf

of the server’s objects
• Demultiplexes requests to the correct
servant Object (servant)
• Dispatches the appropriate operation
upcall on the servant
• Registers classes it supports and their
run-time instances with the IDL
implementation repository DSI
Skeleton
• Portable Object Adapter (POA)
• policies control object behavior Object Adapter
(ie. LifespanPolicy)
• Instance of the adapter design pattern
Object Reference

Client OBJ Object (servant)

Ref
• Interoperable Object Reference (IOR)
• Uniquely identifies each object
• Contents
• Type Name (repository ID)
Object Adapter
• Protocol and Address Details
• Object Key (object adaptor name, object name)
 Request Handling

Server Application
POA

Incoming
Request ORB POA Servants

POA
Scenario

Interface IDL Implementation

Repository Compiler Repository

Client OBJ Object (servant)

Ref

IDL
DSI
IDL ORB Skeleton
DII
Stub Interface
Object Adapter

GIOP/IOOP ORB Core

CORBA Services
 Provide basic infrastructure functionality
 Currently there are 15 defined services
 Naming - maps human names to object references (White
Pages)
 Event - provides both a push and pull event model
 Object Trader - discover objects based on the services they
provide (Yellow Pages)
 Transactions – allows distributed objects to participate in
atomic transactions
CORBA Facilities
 Provide higher-level functionality at the application
level
 Provide standard components that can be used “off-
the-shelf”
 Two Categories
 Horizontal – user interface, information management,
systems management, and task management
 Vertical – domain based, telecommunications, financial
services
ADVANTAGES OF CORBA

 1.OS and programming-language independence.

 Interfaces between clients and servers are defined in OMG IDL, thus
providing the following advantages to Internet programming: Multi-
language and multi-platform application environments, which provide a
logical separation between interfaces and implementation.

 2. Legacy and custom application integration.

 Using CORBA IDL,developers can encapsulate existing and custom
applications as callable client applications and use them as objects on the
ORB.
 3.Rich distributed object infrastructure.
 CORBA offers developers a rich set of distributed object services, such as
the Lifecycle, Events,
 Naming, Transactions, and Security services.

Mr K Zvarevashe, Lecturer, Harare Institute of Technology, Zimbabwe 38

ADVANTAGES OF CORBA…

 4.Location transparency.
 CORBA provides location transparency: An object reference is
independent of the physical location and application level location. This
allows developers to create CORBA-based systems where objects can be
moved without modifying the underlying applications.

 5.Network transparency.
 By using the IIOP protocol, an ORB can interconnect with any ORB
located elsewhere on the network.

 6.Remote callback support.

 CORBA allows objects to receive asynchronous event notification from
other objects.

Mr K Zvarevashe, Lecturer, Harare Institute of Technology, Zimbabwe 39

ADVANTAGES OF CORBA…

 7.Dynamic invocation interface.

 CORBA clients can both use static and dynamic
methods invocations. They either statically define
their method invocations through stubs at compile
time, or have the opportunity to discover objects’
methods at runtime.

 With those advantages, some key factors, which

affected the success of CORBA evident while
implementing CORBA-based distributed
applications, are as follows:
Mr K Zvarevashe, Lecturer, Harare Institute of Technology, Zimbabwe 40
ADVANTAGES OF CORBA…

 (i) High initial investment.

 CORBA-based applications require huge
 investments in regard to new training and the
deployment of architecture, even for small-
scale applications.

 (ii)Availability of CORBA services. The

Object services specified by the OMG are still
lacking as implementation products.
Mr K Zvarevashe, Lecturer, Harare Institute of Technology, Zimbabwe 41
ADVANTAGES OF CORBA…

 Scalability.
 Due to the tightly coupled nature of the
connection oriented CORBA architecture,
very high scalability expected in enterprise
applications may not be achieved.

Mr K Zvarevashe, Lecturer, Harare Institute of Technology, Zimbabwe 42

JAVA RMI

JAVA RMI

08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 43

Session Objectives
 Describe the Java Distributed Model

 Analyse RMI Architeture

 Discuss RMI packages

Distributed Application
 A Distributed application is an application whose
processing is distributed across multiple networked
computers.

 The various models that can be used for developing

distributed applications
 Distributed Component Object Model(DCOM)
 Common Object Request Broker Architecture(CORBA)
 Remote Method Invocation(RMI)
Remote Method Invocation (RMI)
The distributed object model used by Java allows objects
in one JVM to invoke methods of objects in a separate
JVM. This is known as RMI.

Java Virtual Machine Java Virtual Machine

Client Object TCP Server Object

RMI System Layers
 The RMI system consists of three layers in its
architecture:

 Stub/Skeleton Layer

 Remote Reference Layer

 Transport Layer
RMI client

 The RMI client, which can be a Java applet or

a standalone application, performs the
remote method invocations on a server
object.
 It can pass arguments that are primitive data
types or serializable objects.

08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 48

RMI stub

 The RMI stub is the client proxy generated

by the rmi compiler (rmic provided along with
Java developer kit—JDK) that encapsulates
the network information of the server and
performs the delegation of the method
invocation to the server.
 The stub also marshals the method
arguments and unmarshals the return values
 from the method execution.
08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 49
RMI infrastructure

 The RMI infrastructure consists of two layers:

the remote reference layer and the
transport layer.

08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 50

remote reference layer

 The remote reference layer separates out the

specific remote reference behavior from the
client stub.
 It handles certain reference semantics like
connection retries, which are
unicast/multicast of the invocation requests.

08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 51

transport layer

 The transport layer actually provides the

networking infrastructure, which facilitates
the actual data transfer during method
invocations, the passing of formal
arguments, and the return of back execution
results.

08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 52

RMI skeleton

 The RMI skeleton, which also is generated

using the RMI compiler (rmic) receives the
invocation requests from the stub and
processes the arguments (unmarshalling) and
delegates them to the RMI server.
 Upon successful method execution, it
marshals the return values and then passes
them back to the RMI stub via the RMI
infrastructure.
08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 53
RMI server

 The server is the Java remote object that

implements the exposed interfaces and executes
the client requests.
 It receives incoming remote method invocations
from the respective skeleton, which passes the
parameters after unmarshalling.
 Upon successful method execution, return values
are sent back to the skeleton, which passes them
back to the client via the RMI infrastructure.

08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 54

RMI Architecture
Java Virtual Machine Java Virtual Machine

Client Object Server Object ‘S’

Object ‘S’ Stub Object ‘S’ Skeleton

Remote
RemoteReference
Reference Remote
RemoteReference
Reference
Layer
Layer Layer
Layer

TransportLayer
TransportLayer TCP TransportLayer
TransportLayer
Remote Method Invocation API
 The five packages in RMI API are:
 java.rmi
 java.rmi.registry
 java.rmi.server
 java.rmi.activation
 java.rmi.dgc

We shall be examining the first three in detail

The java.rmi Package
 The java.rmi package declares
 The Remote interface

 The MarshalledObject class

 The Naming class

 The RMISecurityManager class

 A number of exceptions that are used with remote

method invocations
The java.rmi.registry Package
 The interfaces and class of the java.rmi.registry
package are used to handle remote objects by
name and also to register those remote objects

 The java.rmi.registry package provides

 The Registry interface

 The RegistryHandler interface

 The LocateRegistry class.

The java.rmi.server Package
 The java.rmi.server package supports both client and
server aspects of RMI like a class implementation of
Remote interface, client stub and server skeleton
 Classes and Interfaces declared are :

 RemoteObject class  Skeleton interface

 RemoteServer class  RMIClassLoader class

 UnicastRemoteObject class  RMISocketFactory class

 RemoteStub class
Implementing RMI
 Implement RMI server
 Create Remote Interface
 Create a class that implements the remote interface
 Create stub and skeleton classes
 Copy Remote interface and stub to client
 Create and register remote objcet

 Implement the RMI client

 Call the remote interface by using the ‘lookup()’
method of the Naming class.
RMI flow - I
Client Virtual Machine Server Virtual Machine

Client Remote Object 1

Stub Skeleton Server

Registry Virtual Machine

1. Server Creates Remote 2
object.
Remote Object
2. Server Registers Remote Registered
object with RMI registry
 RMI flow - II
Client Virtual Machine Server Virtual Machine

Client Remote Object

Server
Stub Skeleton

4
3
Registry Virtual Machine 3. Client requests object from
registry

Remote Object 4. Registry returns remote

Registered
reference through interface
RMI flow - III

Client Virtual Machine Server Virtual Machine

7
Client Remote Object

5 6
Server
Stub Skeleton

Registry Virtual Machine 5. Client invokes stub method

6. Stub talks to skeleton

Remote Object
Registered
7. Skeleton invokes remote
object method.
RMI limitations
 RMI is limited only to the Java platform. It does not provide language
independence in its distributed model as targeted by CORBA.

 RMI-based application architectures are tightly coupled because of the

connection-oriented nature. Hence, achieving high scalability in such
an application model becomes a challenge.

 RMI does not provide any specific session management support. In a

typical client/server implementation, the server has to maintain the
session and state information of the multiple clients who access it.
 Maintaining such information within the server application without a
standard support is a complex task.

08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 64

DCOM
 The Microsoft Component Object Model (COM) provides a
way for Windows-based software components to
communicate with each other by
defining a binary and network standard in a Windows
operating environment.
 COM evolved from OLE (Object Linking and Embedding),
which employed a Windows registry-based object
organization mechanism.

COM provides a distributed application model for ActiveX
components.

08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 65

 Microsoft developed the Distributed Common
Object
Model (DCOM) as its answer to the distributed
computing problem in the
Microsoft Windows platform.
 DCOM enables COM applications to
communicate with each other using an RPC
mechanism, which employs a
DCOM protocol on the wire.

08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 66

 DCOM applies a skeleton and stub approach whereby a defined
interface that exposes the methods of a COM object can be
invoked remotely over a network.
 The client application will invoke methods on such aremote COM
object in the same fashion that it would with a local COMobject.
 The stub encapsulates the network location information of the
COM server object and acts as a proxy on the client side.
 The servers can potentially host multiple COM objects, and when
they register themselves
against a registry, they become available for all the clients, who
then discover them using a lookup mechanism.

08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 67

DCOM ARCHITECTURE

08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 68

DCOMM LIMITATIONS

 Platform lock-in
 State management
 Scalability
 Complex session management issues

08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 69

MOM (Message-Oriented Middleware )

 MOTIVATION
 Although CORBA, RMI, and DCOM differ in their
basic architecture and approach, they adopted a
tightly coupled mechanism of a synchronous
communication model (request/response).
 All these technologies are based upon binary
communication protocols and adopt tight
integration across their logical tiers, which is
susceptible to scalability issues.

08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 70

 Message-Oriented Middleware (MOM) is
based upon a loosely coupled asynchronous
communication model where the application
client does not need to know its application
recipients or its method arguments.
 MOM enables applications to communicate
indirectly using a messaging
provider queue.

08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 71

 The application client sends messages to the
message queue (a message holding area), and the
receiving application picks up the message from
the queue. In this operation model, the
application sending
messages to another application continues to
operate without waiting for
the response from that application.

08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 72

 In MOM-based architecture, applications
interacting with its messaging
infrastructure use custom adapters.
 Client applications communicate with
the underlying messaging infrastructure using
these adapters for sending
and receiving messages.
 For reliable message delivery, messages can be
persisted in a database/file system as well.

08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 73

MOM ARCHITECTURE

08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 74

Message-Oriented Middleware (MOM)
 Communication using messages
 Messages stored in message queues
 message servers decouple client and server
 Various assumptions about message content

Client App. Server App.

Message Servers

local message message local message

queues queues queues

Network Network Network

Middleware 75
Properties of MOM

Asynchronous interaction
 Client and server are only loosely coupled
 Messages are queued
 Good for application integration
Support for reliable delivery service
 Keep queues in persistent storage
Processing of messages by intermediate message server(s)
 May do filtering, transforming, logging, …
 Networks of message servers
Natural for database integration

Middleware 76
IBM MQSeries
 One-to-one reliable message passing using queues
 Persistent and non-persistent messages
 Message priorities, message notification
 Queue Managers
 Responsible for queues
 Transfer messages from input to output queues
 Keep routing tables
 Message Channels
 Reliable connections between queue managers
 Messaging API:

MQopen Open a queue

MQclose Close a queue
MQput Put message into opened queue
MQget Get message from local queue
Middleware 77
Java Message Service (JMS)
 API specification to access MOM implementations
 Two modes of operation *specified*:
 Point-to-point
▪ one-to-one communication using queues
 Publish/Subscribe
▪ cf. Event-Based Middleware

 JMS Server implements JMS API

 JMS Clients connect to JMS servers
 Java objects can be serialised to JMS messages
 A JMS interface has been provided for MQ
 pub/sub (one-to-many) - just a specification?

Middleware 78
Disadvantages of MOM

 Poor programming abstraction (but has evolved)

Rather low-level (cf. Packets)
Request/reply more difficult to achieve, but can be done

 Message formats originally unknown to middleware

No type checking (JMS addresses this – implementation?)

 Queue abstraction only gives one-to-one communication

Limits scalability (JMS pub/sub – implementation?)

Middleware 79
 Most of the standard MOM implementations have
provided native APIs for communication with their
core infrastructure.
 This has affected the portability of applications
across such implementations and has led to a
specific vendor lock-in.
 The MOM messages used for integrating
applications are usually based upon a proprietary
message format without any standard compliance.

08/12/2015 Dr. J. VijiPriya, Assistant Professor, Hawassa University, Ethiopia 80