Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Service-Oriented Architecture: Prof Ehab E. Hassanien Dr. Dina Ezzat

Download as pdf or txt
Download as pdf or txt
You are on page 1of 17

Service-Oriented

Architecture
Prof Ehab E. Hassanien
Dr. Dina Ezzat
Sockets
Sockets

A socket is a communications connection point
(endpoint) that you can name and address in a
network.

The processes that use a socket can reside on the
same system or on different systems on different
networks.

Sockets are useful for both standalone and network
applications.

Socket APIs are the network standard for TCP/IP.
Sockets (cont.)

Sockets allow one application to listen at a given port
on a given machine for the incoming data, while
another application can write to the same socket using
the IP address and port address of the first application.

The listening application can read the data as soon as
the second application writes the data. Thus, the data
is shared in real time and the problem of stale data is
eliminated.

The listening application is usually called a server
whereas the other application is called a client.
Server Sample
import java.io.*;
import java.net.*;
public class MyServer {
public static void main(String[] args){
try{
ServerSocket ss=new ServerSocket(6666);
Socket s=ss.accept(); //establishes connection
DataInputStream dis=new DataInputStream(s.getInputStream());
String str=(String) dis.readUTF();
System.out.println("message= "+str);
ss.close();
}catch(Exception e){System.out.println(e);}
}
}
Client Sample
import java.io.*;
import java.net.*;
public class MyClient {
public static void main(String[]
main args) {
try{
Socket s=new Socket("localhost", 6666);
DataOutputStream dout=new DataOutputStream(s.getOutputStream());
dout.writeUTF("Hello Server");
dout.flush();
dout.close();
s.close();
}catch(Exception e){System.out.println(e);}
}
}
Socket API
Shared Memory

Two applications exchanging data by using


common area in the memory (RAM)
Types of Function Calls
Functions can be synchronous or
asynchronous.
– In the case of synchronous functions, the calling code
is blocked from doing further work until after the
function returns.
– In the case of asynchronous calls, the calling code can
continue to perform other work without waiting for a
return (because there is no return).
Local Function Call


The code calling the function and the function being called are part of the
same application.

The most familiar because most programming languages allow for this feature.

Typically some machine instruction is executed that transfers control to the
new function, and the called function saves machine registers and allocates
space on the stack for the local variables.
Restricted RPC Function call


The restricted RPC type. The code calling the
function and the function code being called reside
in two different applications running on the same
machine.

Remote Procedural Code Between
Different Hosts
RPC Process
we will now outline the basic steps involved in a remote function call. Figure 4.8 summarizes
the steps that take place. The steps are numbered in the order in which they occur.

To begin,

the server is started and registers a temporary port with what is called the port mapper.

The server listens for the incoming call at this port on the host on which the server is
running. Next, the client is started. When the client invokes the function clint_create, it
contacts the port mapper to find the temporary port of the server.

Then the client establishes a TCP connection with the server at this port.


One of the important components introduced in Figure 4.8 is the client stub.

To the client, the client stub appears to be the actual procedure it calls. The

purpose of the stub is to package up the arguments to the remote procedure

(possibly), put them into a standard format, and then build

RPC Process
RPC Process
we will now outline the basic steps involved in a remote function call. Figure 4.8 summarizes
the steps that take place. The steps are numbered in the order in which they occur.

To begin,

the server is started and registers a temporary port with what is called the port mapper.

The server listens for the incoming call at this port on the host on which the server is
running. Next, the client is started. When the client invokes the function clint_create, it
contacts the port mapper to find the temporary port of the server.

Then the client establishes a TCP connection with the server at this port.


One of the important components introduced in Figure 4.8 is the client stub.

To the client, the client stub appears to be the actual procedure it calls. The

purpose of the stub is to package up the arguments to the remote procedure

(possibly), put them into a standard format, and then build

RPC Process
we will now outline the basic steps involved in a remote function call. Figure 4.8 summarizes
the steps that take place. The steps are numbered in the order in which they occur.

To begin,

the server is started and registers a temporary port with what is called the port mapper.

The server listens for the incoming call at this port on the host on which the server is
running. Next, the client is started. When the client invokes the function clint_create, it
contacts the port mapper to find the temporary port of the server.

Then the client establishes a TCP connection with the server at this port.


One of the important components introduced in Figure 4.8 is the client stub.

To the client, the client stub appears to be the actual procedure it calls. The

purpose of the stub is to package up the arguments to the remote procedure

(possibly), put them into a standard format, and then build

Distributed Objects and
Application Servers
RPC has a number of shortcomings that prevent it from being a complete and
satisfactory solution for integrating all applications in a large enterprise. We
will begin to address some of these shortcomings, including the following:
– There is little room for code reuse because the code for marshalling and unmarshalling
and the code for network communication are buried inside the client and server
applications.
– RPC is not language independent. In other words, the server and client applications
must be written in the same programming language. Servers and clients written in two
different programming languages cannot share functionality.
– RPC integrates the client and server applications in a point-to-point manner, which is
not appropriate if a large number of applications need to be integrated. The number of
integrations you need to perform in a point-to-point approach increases rapidly
(roughly N2, where N is the number of applications in an enterprise that are being
integrated).
– On a related note, in RPC the roles of client and server are fixed, and the relationship
between the client and the server is not “peer to peer.” In other words, the client can
access the functionality embedded in the server, but not the other way around.

You might also like