WACHEMO UNIVERSITY

COLLEGE OF ENGINEERING AND TECHNOLOGY

SCHOOL OF COMPUTING AND INFORMATICS
DEPARTMENT OF INFORMATION TECHNOLOGY

Integrative Programming and Technologies

09/06/2025 1
 Intersystem Communications

• Information Technology is the integration of applications and systems.

• It addresses the use of:
• Architectures
• application programming interfaces
• programming practices to facilitate the management
• integration and security of the systems that support an organization.
• Information Technology Architecture: classified into three categories:
• Enterprise Architecture (Company level)
• Solution Architecture (Department level)
• System Architecture (Team level)

09/06/2025 2
What is Intersystem
Communication?
• Is the communication between the set of heterogeneous systems that
are integrated together through objects.
• Challenges in Intersystem communication
• New Function or New Technology Integration: integrating the new technology
with the existing system with preserving the original system functionality is a
challenge.
• Incremental Engineering
• Modification

09/06/2025 3
 Basics of Distributed Systems
Integrative Technologies
 A DS is a collection of autonomous computers linked by a network and equipped with
distributed system software.
 A well-developed distributed system software provides the illusion of a single and integrated
environment although it is actually implemented by multiple computers in different
locations.
 This software enables computers to coordinate their activities and to share the resources of the system
hardware, software, and data.
 A distributed system has six important characteristics, which you have learned in our
previous.
 Resource sharing
 Openness
 Concurrency
 Scalability
 Fault tolerance
 Transparency
09/06/2025 4
Middleware in Distributed
System
• Middleware in distributed systems is a type of distributed system
software which connects different kinds of applications and provides
distribution transparency to its connected applications.
• It is used to bridge heterogeneities that occurred in the systems.

09/06/2025 5
Introduction to Middleware Technologies

• What is Middleware?
• General Middleware
• Service Specific Middleware
• Client/Server Building blocks
• RPC
• Messaging
• Peer – to – Peer
• Java RMI.
 Cont…
 The middleware layer uses protocols based on messages between
processes to provide its higher-level abstractions such as remote
invocation and events.
 middleware – software layer providing:
 programming abstraction
 masking heterogeneity of:
 underlying networks
 Hardware
 operating systems
 Prog. Language
 developers

7
Middleware

1-22

General structure of a distributed system as middleware.

 Middleware Metaphorically

Host 1 Host 2

Distributed application Distributed application

Middleware Middleware

Operating system Operating system

Network
Middleware Systems
• Middleware systems are comprised of abstractions and services to facilitate the
design, development, integration and deployment of distributed applications in
heterogeneous networking environments.
• remote communication mechanisms (Web services, CORBA, Java RMI, DCOM
- i.e. request brokers)
• event notification and messaging services (COSS Notifications, Java Messaging
Service etc.)
• transaction services
• naming services (COSS Naming, LDAP)
•…
 What & Where is Middleware ?

Programming
Databases
Languages
Middleware Distributed
Operating Systems Systems
Systems
Networking

• middleware is dispersed among many disciplines

 Categories of Middleware

• remote invocation mechanisms

– e.g., DCOM, CORBA, DCE, Sun RPC, Java RMI, Web Services ...
• naming and directory services
– e.g., JNDI, LDAP, COSS Naming, DNS, COSS trader, ...
• message oriented middleware
– e.g., JMS, MQSI, MQSeries, ...
• publish/subscribe systems
– e.g., JMS, various proprietary systems, COSS Notification
 The “ilities”

• Reliability
• Availability Before using a specific
middleware, always make sure
• Security that the “ilities” aka non-
• functional requirements are
Scalability met. Middleware almost
• Quality always differs implementation
quality between vendors.
• Performance
• Maintainability
• Middleware can be divided into several categories:
• Socket
• RPC (Remote Procedure Call)
• RMI (Remote Method Invocation)
• DCE (Distributed Computing Environment)
• DCOM (Distributed Component Object Model) and
• CORBA (Common Object Request Broker Architecture).
• Message Oriented Middleware (MOMs)

09/06/2025 15
 The Questions
• What are the right programming abstractions for middleware systems?
• What protocols do these abstractions require to work as promised?
• What, if any, of the underlying systems (networks, hardware, distribution)
should be exposed to the application developer?
– Views range from
• full distribution transparency to
• full control and visibility of underlying system to
• fewer hybrid approaches achieving both
– With each having vast implications on the programming abstractions offered
 Client-Server Communication

• Sockets
• Remote Procedure Calls
• Remote Method Invocation (Java)
 Sockets

• A socket is defined as an endpoint for communication.

• Concatenation of IP address and port
• The socket 161.25.19.8:1625 refers to port 1625 on host 161.25.19.8
• Communication consists between a pair of sockets.
• Considered a low-level form of communication between distributed processes.
– Sockets allow only an unstructured stream of bytes to be exchanged. It is the responsibility
of the client or server application to impose a structure on the data.
Socket Communication
Socket
• A socket is a peer-to-peer communication endpoint.
• Sockets enable processes that reside in different computers to
communicate to each other.
• They provide the basic infrastructure needed to facilitate
communications in distributed systems.
• Used as interfaces from the upper three layers of the OSI model into
the transport layer.

09/06/2025 20
RPC
• Procedures in process on remote computers can be called if they are
procedures in the local address space.
• It supports client server computing services
• It helps in access and location transparency
• Not object oriented framework
• Used for communication between programs in the same language.

09/06/2025 21
 Remote Procedure Calls

• Remote procedure call (RPC) abstracts procedure calls between

processes on networked systems.
• Stub – client-side proxy for the actual procedure on the server.
Server has a similar stub as well.
• The client-side stub locates the server and marshals the parameters.
• The server-side stub receives this message, unpacks the marshaled
parameters, and performs the procedure on the server.
• External data representation (XDR) I.e most-significant (big-
endian), least-significant(little-endian)
Roles of client stub and server stub
Client stub Server stub

Identify the address of server stub procedures Receive request from client stub
Convert parameters of remote call into block of Unmarshal the parameters
byte suitable for transmission across network
(parameter marshalling)

Send request to server stub Call server

Wait for reply and Unmarshal parameters Catch any exceptions raised by the server
Return control to the client the returned Marshal the return parameters suitable for
parameters transmission across the network

Send the reply to the client

09/06/2025 23
 Remote Method Invocation

• Remote Method Invocation (RMI) is a Java mechanism similar to RPCs.

• RMI allows a Java program on one machine to invoke a method on a remote
object.
Local v. Remote method invocation

09/06/2025 25
 Introduction to RMI

• RMI
– Register method as remotely accessible
• Client can look up method and receive a reference
• Use reference to call method
• Syntax same as a normal method call
– Marshalling of data
• Can transfer objects as well
• Class ObjectOutputStream converts Serializable object into stream of bytes
– Transmit across network
• Class ObjectInputStream reconstructs object
– No Interface Definition Language needed
• Use Java's own interface
Remote Method Invocation (RMI)-
Sun Microsystem
• RMI is a Java-based middleware that allows methods of Java objects located in a Java Virtual
Machine (JVM) to be invoked (accessed) from another JVM (across a network).
• RMI is used to build distributed applications; it provides remote communication between Java
programs.
• It is provided in the package java.rmi.
• RMI was introduced by JavaSoft with JDK 1.1+ and is essentially object-oriented Java RPC.
• An RMI application consists two programs:
• server program (resides on the server)
• client program (resides on the client).
• Both use IDL to describe the distributed system software interfaces (i.e., methods for RMI and
procedures for RPC(Remote Procedure Call)) involved.
• RMI does have some differences compared to RPC.
• The first one is that, IDL in RPC is usually based on procedural C, while IDL in RMI is based on
object-oriented Java.
• The J2EE platform integrated RMI with IIOP.
09/06/2025 27
 Case Study: Creating a Distributed System with
RMI
• Four major steps
– Define remote interface
• Describes client/server communication
– Define server application to implement remote interface
• Same name as remote interface, ends with Impl
– Define client application that uses remote interface reference
• Interacts with server implementation
– Compile and execute server and client
RMI System Architecture
• Built in three layers (they are all independent):
• Stub/Skeleton layer
• Remote reference layer
• Transport layer
• built using specific interface.
• RMI is TCP/UDP based

09/06/2025 29
How does RMI work?
• It uses IDL to describe distributed system interfaces
• The transport layer is responsible for setting up the connection
• Inside the server program, a remote object is created and reference of
that object is made available for the client (using the registry).
• The client program requests the remote objects on the server and tries
to invoke its methods.
• An invocation will pass through the stub/skeleton layer, which will
transfer data to the remote reference layer
• The semantics of the invocation are carried to the transport layer

09/06/2025 30
The Stub/Skeleton layer
• Stub ─ A stub is a representation (proxy) of the remote object at
client.
• It resides in the client system; it acts as a gateway for the client program.
• Skeleton ─ This is the object which resides on the server side.
• it communicates with this skeleton to pass request to the remote object.
• not required in JDK1.2-only environments
• The interface between the application layer and the rest of the
system
• Stubs and skeletons are generated using the RMIC compiler
• This layer transmits data to the remote reference layer via the
abstraction of marshal streams (that use object serialization)
• This layer doesn’t deal with the specifics of any transport
09/06/2025 31
The Stub/Skeleton l
• Client stub responsible for:
• implements the remote interface- initiates connection with JVM
• Initiate remote object calls
• Marshal arguments to be sent
• Inform the remote reference layer to invoke the call
• Unmarshaling the return value
• Inform remote reference the call is complete
• Server skeleton responsible for:
• Unmarshaling incoming arguments from client
• Calling the actual remote object implementation
• Marshaling the return value for transport back to client
N.B. Both communicate via the network.

09/06/2025 32
The Remote Reference Layer
• RRL (Remote Reference Layer) ─ It is the middle layer which
manages the references made by the client to the remote object.
• Provides the ability to support varying remote reference or invocation
protocols independent of the client stubs and server skeletons
• Example: the unicast protocol provides point-to-point invocation, and
multicast to replicated groups of objects, other protocols may deal
with different strategies (replication or persistent references to remote
objects)
• Not all these features are supported….supported only by Java2

09/06/2025 33
 The Transport Layer

• A low-level layer that ships serialized objects between different

address spaces
• Responsible for:
• Setting up connections (new) to remote address spaces
• Managing the existing connections
• Listening and setting up to incoming calls
• Maintaining a table of remote objects that reside in the same address
space
• Locating the dispatcher for the target of the remote call

09/06/2025 34
Marshalling and Unmarshalling
• When a client code invokes a remote method on a remote object, it actually calls an ordinary/local Java method
encapsulated in the stub.
• The stub encodes the parameters used in the remote method with a device-independent encoding and transforms
them in a format suitable for transport.
• The process of encoding, writing to a stream and sending an object is referred as parameter marshalling.
• When a client invokes a remote method on a remote object, that accepts parameters on a remote object, the
parameters are bundled into a message before being sent over the network.
• Identifier of remote object to be used;
• Name of the method to be called
• The parameters are put together and a header is attached to it if they are primitive data types.
• In case the parameters are objects, then they are serialized.
• This process is known as marshalling.
• At the server side, the packed parameters are unbundled and then the required method is invoked.
• The reverse process of receiving, reading and decoding is called parameter unmarshalling.

09/06/2025 35
Marshalling Parameters
RMI Registry

• RMIregistry is a namespace on which all server objects are placed.

• Each time the server creates an object, it registers this object with the
RMIregistry (using bind() or reBind() methods).
• These are registered using a unique name known as bind name.
To invoke a remote object, the client needs a reference of that object.
• At that time, the client fetches the object from the registry using its bind name
(using lookup() method).
• The remote object must register itself with the RMI naming registry
• A reference to the remote object is obtained by the client by looking up the
registry.

09/06/2025 37
Java Garbage Collection
• In stand-alone application object that are no longer referenced by any client are
automatically deleted.
• RMI provides distributed garbage collector that automatically delete/removes objects
that are no longer referenced by any client.
• RMI uses a reference counting garbage collection algorithm that keeps track of all
live references of a given object on each JVM.
• When a live reference enters a JVM its count is incremented, when it becomes
unreferenced, its count is decremented; when the count is 0 (no live reference) the
object can be garbage collected.
• Every time a connection is established to an object, its reference count is
incremented.
• As long as there is a local reference to a remote object it cannot be garbage collected,
since it can be passed to remote server or returned to a client.
09/06/2025 38
 Remote Method Invocation

• RMI and RPC differs in two ways:

1. RPCs support procedural programming whereby only remote procedures or
functions may be called. RMI is object based: It supports invocation of methods
on remote objects.
2. The parameters to remote procedures are ordinary data structures in RPC; with
RMI it is possible to pass objects as parameters to remote methods.

• If the marshaled parameters are local (non remote) objects, they are passed by
copy using a technique known as object serialization.
– Object serialization allowed the state of an object to be written toa byte stream.
 Session 1 Complete
09/06/2025 40
Distributed Component Object Model
(DCOM)-Microsoft
• DCOM is a middleware developed by Microsoft that provides a distributed
framework based on object-oriented model.
• It is the distributed extension to the Component Object Model (COM),
which provides an Object Remote Procedure Call (ORPC) on top of DCE
RPC.
• DCOM is the latest incarnation of Microsoft’s object technology which
starts its live from mid-1980s as Dynamic Data Exchange (DDE), that is, an
inter-process communication protocol designed by Microsoft that allows
applications to exchange messages via shared memory.
• Later, it evolved to Object Linking and Embedding (OLE), to COM, and
finally to DCOM.
09/06/2025 41
 DCOM Architecture

09/06/2025 42
• DCOM services are divided into two parts:
• OLE and COM.
• COM provides the underlying object system on which OLE services
rely upon.
• 3 COM services are:
• Uniform data transfer service is a COM service that provides the basic
facilities to exchange data between applications.
• Moniker service provides the mechanism to name objects for their
identifications.
• Persistent storage service allows objects to be stored in the disk.

09/06/2025 43
OLE (Object Linking and
Embedding)
• OLE part contains three services:
1. Compound documents services
provides the ability to link information in a document through three services:
• In-place activation
• enables container applications to hold component objects, permitting the user to manipulate component application
operations.
• Linking
• enables multiple applications to share common data.
• Embedding
• allows container objects to have separate copies of the same data.
2. drag-and-drop services
permits users to add OLE objects by dragging and dropping them into their containers.
3. Automation services
allows developers to reuse existing components for building a new application by exposing
their operations.
09/06/2025 44
• DCOM follows the RPC and RMI approach of using IDL to declare the methods
which should be made accessible to clients.
• Compared to sockets, RMI, and RPC, DCOM provides a higher-level abstraction
for developing distributed software.
• The DCOM’s focus on desktops makes it problematic to extend DCOM to
enterprise architecture.

09/06/2025 45
 The Common Object Request Broker Architecture (CORBA)-OMG

 The Object Management Group (OMG) was formed in 1989. Its aims were:
 to make better use of distributed systems
 to use object-oriented programming
 to allow objects in different programming languages to communicate with one another
 The object request broker (ORB) enables clients to invoke methods in a remote
object
 CORBA 1 in 1989 and CORBA 2 in 1996.
 The CORBA is a standard architecture for a distributed objects system.
 CORBA is designed to allow distributed objects to interoperate in a heterogenous
environment, where objects can be implemented in different programming language
and/or deployed on different platforms
 CORBA differs from the architecture of Java RMI in one significant aspect:
 RMI is a proprietary facility developed by Sun MicroSystems, Inc., and supports objects
written in the Java programming language only.
09/06/2025 46
 Object Brokers - History
 1990s – object oriented programming
 similar to RPC
 Problem: object oriented features

 CORBA by OMG
 Common Object Request Broker Architect.
 DCOM / COM+ (Microsoft)
 CORBA is not in itself a distributed objects facility; instead, it is a set of
protocols.
 A distributed object facility which adhere to these protocols is said to be
CORBA-compliant, and the distributed objects that the facility support
can interoperate with objects supported by other CORBA-compliant
facilities.
 CORBA is a very rich set of protocols. We will instead focus on the key
concepts of CORBA related to the distributed objects paradigm. We will
also study a facility based on CORBA: the Java IDL.

09/06/2025 48
 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

09/06/2025 49
 CORBA – System Architecture

Vertical facilitites
Financials Health care ... CORBA
user- Horizontal facilities
facilities
definied Distributed Systems
documents management
Information Task
objects management management

Object Request Broker (ORB)

CORBA
naming transactions events lifecycle properties services
relationships time licensing trader concurrency

query security collection startup persistence

 CORBA – How it works

IDL of service provider

application IDL compiler IDL compiler

object (client) (server side)
(client) application object application object
(client) (service provider)
stub skeleton
Dynmic Invocation Interface
Object Request Broker (ORB)

Interface repository
 Dynamic Service Selection
 Dynamically discover new objects
 Interface repository (stores IDL definitions)
 Dynamic invocation interface
 Naming and Trader services

 In practice NOT used!

 meaning of the properties, parameters?
 Encapsulation

 Hides internal details

 Change implementation
 Change programming language
 Change platform/operating system
 Change location (General Inter-ORB Protocol )
 How to meet goals?
 Interface Definition Language (IDL)
 Language Independence
 Defines Object Interfaces
 Hides underlying object implementation
 Language mappings exist for C, C++, Java, Python, Cobol, Smalltalk,
and Ada
 Object Request Broker (ORB)

09/06/2025 54
 IDL Compiler

IDL
Definitions 1. Define objects using IDL
2. Run IDL file through IDL compiler
3. Compiler uses language mappings to generate
programming language specific stubs and skeletons
IDL compilers automate the use of this language mapping by
translating an IDL specification to the corresponding code in
one of the programming languages mentioned.

09/06/2025 55
 The Basic Architecture

n am in g
look u p
o bje ct
n a m in g s e rv ice o bje ct clie n t
im ple m e n ta tio n

s tu b s k e le to n

ORB ORB

n e two rk n e two rk

o pe ra tin g o pe ra tin g
s y s te m s y s te m

lo g ica l da ta flo w
ph y s ica l da ta flo w

09/06/2025 56
 Cross-language CORBA application

o bje ct im ple m e n ta tio n writte n

o bje ct clie n t writte n in J a v a
in C + +

stu b i n Java ge n e rate d by com pi l i n g s k e le to n in C ++ g e n e r a t e d b y

co m pi l i n g th e C O R B A o bje ct
th e C O R B A o b j e c t i n t e r f a c e
i n te rfa ce

O R B writte n in J a v a O R B writte n in C + +

09/06/2025 57
 Inter-ORB Protocols
 To allow ORBs to be interoperable, the OMG specified a protocol
known as the General Inter-ORB Protocol (GIOP), a
specification which “provides a general framework for protocols to
be built on top of specific transport layers.”
 A special case of the protocol is the Inter-ORB Protocol (IIOP),
which is the GIOP applied to the TCP/IP transport layer.

09/06/2025 58
 Inter-ORB Protocols
The IIOP specification includes the following elements:
1. Transport management requirements: specifies the connection and
disconnection requirements, and the roles for the object client and object
server in making and unmaking connections.
2. Definition of common data representation: a coding scheme for
marshalling and unmarshalling data of each IDL data type.
3. Message formats: The messages allow clients to send requests to object
servers and receive replies.
 A client uses a Request message to invoke a method declared in a
CORBA interface for an object and receives a reply message from the
server.

09/06/2025 59
 Object Bus
 An ORB which adheres to the specifications of the IIOP may
interoperate with any other IIOP-compliant ORBs over the Internet.
This gives rise to the term “object bus”, where the Internet is seen as a
bus that interconnects CORBA objects
CO RB A CO RB A CO RB A
o bj e c t o bj e c t o bj e c t

ORB ORB ... ORB

Th e I n te rn e t

09/06/2025 60
 Object Servers and Object Clients
 As in Java RMI, a CORBA distributed object is exported by an
object server, similar to the object server in RMI.
 An object client retrieves a reference to a distributed object
from a naming or directory service, to be described, and
invokes the methods of the distributed object.

09/06/2025 61
 CORBA Object References
 As in Java RMI, a CORBA distributed object is located using an object
reference.
 Since CORBA is language-independent, a CORBA object reference is an
abstract entity mapped to a language-specific object reference by an
ORB, in a representation chosen by the developer of the ORB.
 For interoperability, OMG specifies a protocol for the abstract CORBA
object reference object, known as the Interoperable Object Reference
(IOR) protocol.

09/06/2025 62
 Interoperable Object Reference (IOR)
 For interoperability, OMG specifies a protocol for the abstract
CORBA object reference object, known as the Interoperable
Object Reference (IOR) protocol.
 An ORB compatible with the IOR protocol will allow an object
reference to be registered with and retrieved from any IOR-
compliant directory service. CORBA object references
represented in this protocol are called Interoperable Object
References (IORs).

09/06/2025 63
 Interoperable Object Reference (IOR)
An IOR is a string that contains encoding for the following
information:
 The type of the object.
 The host where the object can be found.
 The port number of the server for that object.
 An object key, a string of bytes identifying the object.
The object key is used by an object server to locate the object.

09/06/2025 64
 CORBA Naming Service
 CORBA specifies a generic directory service.
 The Naming Service serves as a directory for CORBA objects, and, as
such, is platform independent and programming language independent.
 The Naming Service permits ORB-based clients to obtain references to
objects they wish to use.
 It allows names to be associated with object references.
 Clients may query a naming service using a predetermined name to
obtain the associated object reference.

09/06/2025 65
 CORBA Naming Service
 CORBA object server contacts a Naming Service to bind a symbolic
name to the object.
 The Naming Service maintains a database of names and the objects
associated with them.
 To obtain a reference to the object, an object client requests the Naming
Service to look up the object associated with the name (This is known as
resolving the object name.)
 The API for the Naming Service is specified in interfaces defined in IDL,
and includes methods that allow servers to bind names to objects and
clients to resolve those names.

09/06/2025 66
 CORBA Naming Service
 To be as general as possible, the CORBA object naming
scheme is necessary complex.
 Since the name space is universal, a standard naming hierarchy
is defined in a manner similar to the naming hierarchy in a file
directory n a m in g co n te x t 1

n a m in g co n te x t 1 ... n a m in g co n te x t2
...
n a m in g co n te x t 1 ... n a m in g co n te x t 1

...
o bje ct o bje ct
nam e 1 nam e n

09/06/2025 67
 A Naming Context
 A naming context correspond to a folder or directory in a file hierarchy,
while object names corresponds to a file.
 The full name of an object, including all the associated naming contexts,
is known as a compound name.
 The first component of a compound name gives the name of a naming
context, in which the second component is accessed.
 This process continues until the last component of the compound name
has been reached.
 Naming contexts and name bindings are created using methods provided
in the Naming Service interface.

09/06/2025 68
 A CORBA object name
The syntax for an object name is as follows:
<naming context > …<naming context><object name>

where the sequence of naming contexts leads to the object name.

 Example of a naming hierarchy
 As shown, an object representing the men’s clothing department is named store.clothing.men,
where store and clothing are naming contexts, and men is an object name.
s to r e

c lo th in g Ap p lian c es ...

...
w o m en m en telev is io n

09/06/2025 69
 Interoperable Naming Service (INS)
 It is a URL-based naming system based on the CORBA Naming Service,
 It allows applications to share a common initial naming context and
provide a URL to access a CORBA object.

09/06/2025 70
 CORBA Object Services
CORBA specify services commonly needed in distributed applications, some of which
are:
 Naming Service:
 Concurrency Service:
 Event Service: for event synchronization;
 Logging Service: for event logging;
 Scheduling Service: for event scheduling;
 Security Service: for security management;
 Trading Service: for locating a service by the type (instead of by name);
 Time Service: a service for time-related events;
 Notification Service: for events notification;
 Object Transaction Service: for transactional processing.
Each service is defined in a standard IDL that can be implemented by a developer of
the service object, and whose methods can be invoked by a CORBA client.

09/06/2025 71
 Object Adapters
 In the basic architecture of CORBA, the implementation of a
distributed object interfaces with the skeleton to interact with
the stub on the object client side. As the architecture evolved, a
software component in addition to the skeleton was needed on
the server side: an object adapter.
dis tribu te d o bje ct
im ple m e n ta tio n

o bje ct a da pte r

ORB

09/06/2025 72
 Object Adapter
 An object adapter simplifies the responsibilities of an ORB by
assisting an ORB in delivering a client request to an object
implementation.
 When an ORB receives a client’s request, it locates the object
adapter associated with the object and forwards the request to
the adapter.
 The adapter interacts with the object implementation’s skeleton,
which performs data marshalling and invoke the appropriate
method in the object.

09/06/2025 73
 The Java IDL (Java 1.4 version)
 IDL is part of the Java 2 Platform, Standard Edition (J2SE).
 The Java IDL facility includes a CORBA Object Request
Broker (ORB), an IDL-to-Java compiler, and a subset of
CORBA standard services.
 In addition to the Java IDL, Java provides a number of
CORBA-compliant facilities, including RMI over IIOP, which
allows a CORBA application to be written using the RMI
syntax and semantics.

09/06/2025 74
 Distributed Objects
CORBA RMI

• Object Request Broker • Java only (e.g.Introspection

• Multi-language support used)
(platform independence) • Lightweight method call
• Interface Definition semantics
language • Java Implementations
• Wire Protocoll: IIOP, • Wire Protocoll now mostly:
GIOP RMI over IIOP

Both try to preserve object semantics. Interface/Implementation

separation
 Web Services

09/06/2025 76
09/06/2025 77
09/06/2025 78
09/06/2025 79
 Web Services-W3C
 W3C 2003:
 A Web service supports direct interactions with other software
agents using XML-based message exchanges via Internet-based
protocols.
 A web service is any piece of software that makes itself available over
the internet (by URI), whose interfaces and bindings and uses a
standardized XML messaging system via Internet based protocols.
 XML is used to encode all communications to a web service.
 Web services are self-contained, modular, distributed, dynamic
applications that can be described, published, located, or invoked over
the network to create products, processes, and supply chains.

09/06/2025 80
 History
 Structured programming
 Object-oriented programming
 Distributed computing
 Electronic data interchange
 World Wide Web
 Web services [1999]
 Microsoft introduced the name "web services" in June 2000

09/06/2025 81
09/06/2025 82
 What is a Web Service

 A web service is a network accessible interface to application

functionality, built using standard Internet technologies.
 Clients of web services do NOT need to know how it is
implemented.

Application Application
Network Web
client Service code

09/06/2025 83
 What is a Web Service ?

 Web service is a means by which computers talk to each

other over the web using HTTP and other universally
supported protocols.
A Web service is an application that:
 Runs on a Web server
 Exposes Web methods to interested callers
 Listens for HTTP requests representing commands to invoke Web
methods
 Executes Web methods and returns the results

09/06/2025 84
 These applications can be local, distributed, or web-based. Web services
are built on top of open standards such as TCP/IP, HTTP, Java, HTML,
and XML.
 Web services are XML-based information exchange systems that use the
Internet for direct application-to-application interaction. These systems
can include programs, objects, messages, or documents.
 A web service is a collection of open protocols and standards used for
exchanging data between applications or systems.
 Is not tied to any one operating system or programming language

09/06/2025 85
09/06/2025 86
 Web Service is a technology to communicate one programming language
with the other.
 For Example, Java programming language can interact with PHP
and .NET through web service.

09/06/2025 87
 Software applications written in various programming languages and
running on various platforms can use web services to exchange data over
computer networks like the Internet in a manner similar to inter-process
communication on a single computer.
 This interoperability (e.g., between Java and Python, or Windows and
Linux applications) is due to the use of open standards.
 A complete web service is, therefore, any service that −
 Is available over the Internet or private (intranet) networks
 Uses a standardized XML messaging system
 Is not tied to any one operating system or programming language
 Is self-describing via a common XML grammar
 Is discoverable via a simple find mechanism
09/06/2025 88
 Why Web Services?
 Interoperable
 applications to talk to each other and share data and services among themselves.
 .NET application can talk to Java web services
 Easy to use
 Reusable
 Exposing the Existing Function on the network
 A web service is a unit of managed code that can be remotely invoked using HTTP, that
is, it can be activated using HTTP requests.
 Ubiquitous
 Standardized Protocol
 Low Cost of Communication

09/06/2025 89
 Web Services is based on: [Components]
 HTTP (Hypertext Transport Protocol)
 The basic web services platform is XML -eXtensible Mark up Language –to tag the data HTTP.
 SOAP (Simple Object Access Protocol)
 to transfer a message
 WSDL-Web Services Description Language
 to describe the availability of service
 UDDI (Universal Description, Discovery and Integration)
 WS-POLICY (Web Services Policy)
 Most Web services expect their Web methods to be invoked using HTTP requests
containing SOAP messages.
 SOAP is an XML-based vocabulary for performing remote procedure calls using
HTTP and other protocols.

09/06/2025 91
 WEB SERVICES - COMPONENTS

 A web service enables communication among various applications by

using open standards such as HTML, XML, WSDL, and SOAP.
 The basic web services platform is XML + HTTP.
 HTTP:
 Stands for Hypertext Transfer Protocol.
 Is used by Web services to transfer the SOAP-formatted documents between
cooperating computers.

09/06/2025 92
 XML-RPC
 This is the simplest XML-based protocol for exchanging information
between computers.
 protocol that uses XML messages to perform RPCs.
 Requests are encoded in XML and sent via HTTP POST.
 Responses are embedded in the body of the HTTP response.
 Platform-independent.
 allows diverse applications to communicate.
 A Java client can speak XML-RPC to a Perl server.
 The easiest way to get started with web services.

09/06/2025 93
 SOAP
 An XML-based protocol for exchanging information between computers.
 It is a communication protocol.
 Used for communication between applications.
 It is a format for sending messages.
 Designed to communicate via Internet.
 Platform independent.
 Language independent.
 Simple and extensible.
 Allows you to get around firewalls.
 Developed as a W3C standard.

09/06/2025 94
 WSDL- Web Services Description Language
 It is an XML-based language for describing web services and how to access them.
 Was developed jointly by Microsoft and IBM.
 It is an XML based protocol for information exchange in decentralized and
distributed environments.
 Is the standard format for describing a web service.
 Describes how to access a web service and what operations it will perform.
 Is a language for describing how to interface with XML-based services.
 Is an integral part of UDDI, an XML-based worldwide business registry.
 Is the language that UDDI uses.
 Pronounced as 'wiz-dull' and spelled out as 'W-S-D-L'

09/06/2025 95
 WSDL describes the functionality offered by web service.
 How the service can be called
 What parameters it expects
 What data structure it returns

09/06/2025 96
 UDDI- Universal Description, Discovery, and Integration.
 Is an XML-based standard for describing, publishing, and finding web services.
 Is a specification for a distributed registry of web services.
 Is platform independent, open framework.
 Can communicate via SOAP, CORBA, and Java RMI Protocol.
 Uses WSDL to describe interfaces to web services.
 Is seen with SOAP and WSDL as one of the three foundation standards of web
services.
 Is an open industry initiative enabling businesses to discover each other and define
how they interact over the Internet.

09/06/2025 97
 WEB SERVICES - ARCHITECTURE
 There are two ways to view the web service architecture:
The first is to examine the individual roles of each web service actor.
 The second is to examine the emerging web service protocol stack.

09/06/2025 99
09/06/2025 100
There are three major roles within the web service architecture:
 Service Provider
 implements the service and makes it available on the Internet.
 Service Requestor (consumer )
 utilizes an existing web service by opening a network connection and sending an XML request.
 Service broker (Registry)
 centralized directory of services
 provides a central place where developers can publish new services or find existing ones.
 Three basic operations: publish, find and bind respectively.

09/06/2025 101
 Web Service Protocol Stack

 The stack has four main layers.

 Service Transport
 This layer is responsible for transporting messages between
applications.
 Hyper Text Transport Protocol HTTP
 Simple Mail Transfer Protocol SMTP
 File Transfer Protocol FTP, and
 newer protocols such as Blocks Extensible Exchange Protocol BEEP.

09/06/2025 102
 XML Messaging
 responsible for encoding messages in a common XML format so that messages can be understood
at either end.
 Currently, this layer includes XML-RPC and SOAP.
 Service Description
 responsible for describing the public interface to a specific web service.
 Currently, service description is handled via the Web Service Description Language WSDL.
 Service Discovery
 responsible for centralizing services into a common registry and providing easy
publish/find functionality.
 Currently, service discovery is handled via Universal Description, Discovery, and Integration
UDDI.

09/06/2025 103
09/06/2025 104
09/06/2025 105
 Web Service Technology Stack
shopping web service?
Discovery
Discovery Web Service UDDI
WSDL URIs
Client

Description
Description Web Service
WSDL
WSDL
SOAP pkg request
Packaging
Packaging Proxy
SOAP pkg response

Transport
Transport

Network
Network

09/06/2025 106
 Step1. Write Web Service Method
shopping web service?
Discovery
Discovery Web Service UDDI
WSDL URIs
Client

Description
Description Web Service
WSDL
WSDL
SOAP pkg request
Packaging
Packaging Proxy
SOAP pkg response

Transport
Transport

Network
Network

09/06/2025 107
 Step2. Describe Web Service using WSDL
shopping web service?
Discovery
Discovery Web Service UDDI
WSDL URIs
Client

Description
Description Web Service
WSDL
WSDL
SOAP pkg request
Packaging
Packaging Proxy
SOAP pkg response

Transport
Transport

Network
Network

09/06/2025 108
 Step3. Write Proxy to Access Web Service
shopping web service?
Discovery
Discovery Web Service UDDI
WSDL URIs
Client

Description
Description Web Service
WSDL
WSDL
SOAP pkg request
Packaging
Packaging Proxy
SOAP pkg response

Transport
Transport

Network
Network

09/06/2025 109
 Step4. Write Client to Invoke Proxy
shopping web service?
Discovery
Discovery Web Service UDDI
WSDL URIs
Client

Description
Description Web Service
WSDL
WSDL
SOAP pkg request
Packaging
Packaging Proxy
SOAP pkg response

Transport
Transport

Network
Network

09/06/2025 110
 Step1. Create a Web Service
• Functionality is implemented in .asmx.vb or .asmx.cs
files.
– <%@WebService Language=“C#” Class=“helloWorld” %>
• Use System.Web.Services Namespace
– Using System.Web.Services
• Inherit your own class from WebService Base Class
– public class helloWorld : System.Web.Services.WebService
• Declare the WebMethod Attribute
– [WebMethod]
public string HelloWorld(string name)
{…}
09/06/2025 111
 Creating a Web Service with .Net

09/06/2025 112
 Creating a Web Service with .Net

09/06/2025 113
 Creating a Web Service with .Net

09/06/2025 114
 Creating a Web Service with .Net

09/06/2025 115
 Creating a Web Service with .Net

[WebMethod]
public string HelloWorld(string name)
{
return "Hello " + name;
}

09/06/2025 116
 Compile and View Your Web Service

09/06/2025 117
 Compile and View Your Web Service

09/06/2025 118
 Compile and View Your Web Service

09/06/2025 119
 Step2. Describe Web Service using WSDL
• WSDL (Web Services Description Language)
• Describes 3 ways to access web service: GET, POST, SOAP
• Element:
– <types>: XML schema for input/output
– <message>:
• HelloWorldSoapIn, …SoapOut, …HttpGetIn, …HttpGetOut, …
HttpPostIn, …HttpPostOut
– <porttype>
• helloWorldSoap, …HttpGet, …HttpPost
– <binding>
• s0:helloWorldSoap, s0:…HttpGet, s0:…HttpPost
– <service name = “helloWorld”>
<port name = “…Soap” binding = “s0:…Soap”>
<soap:address location = “http://…”/>
</port></service>
09/06/2025 120
 WSDL Generated by .NET

09/06/2025 121
 WSDL Generated by .NET

09/06/2025 122