One

Step
At A
Time

DISTRIBUTED PROGRAMMING
Detailed Lesson notes with practical exercises and applications in Distributed Programming

MODULE 4
JAVA INTERFACE DEFINITION LANGUAGE (JIDL)

By Mr. NYAMBI BLAISE

PhD Student/PLET in Computer Science
Masters in Industrial Computing & Electronics
Software Engineer
Tel: 679194380
masterb.ise@gmail.com

Version : December 2021

Objectives
Upon successful completion of this module, you should be able to:
• Demonstrate knowledge of the JIDL
• Understand and Explain the concepts of CORBA.
• Develop Applications Using the CORBA Architecture.
• Differentiate Between RMI and CORBA.
• Understand The Major Components That Make Up The CORBA

Table of Contents
1 General Introduction .................................................................................................................................. 2
1.1 Recall on Java Interfaces .................................................................................................................... 2
2. Common Object Request Brokerage Architecture (CORBA) .................................................................. 4
2.0 Major Components That Make Up The CORBA Architecture........................................................... 6
2.1 Interface Definition Language (IDL) .................................................................................................. 6
2.1.1 IDL, Interfaces And Implementations.......................................................................................... 7
2.2 Object Request Broker (ORB) ............................................................................................................ 7
2.3 The Naming Service ........................................................................................................................... 8
2.4 Steps To Develop A CORBA Application ......................................................................................... 9
2.4.1 App 1 - CORBA Application To Display A Message ............................................................... 10
2.4.2 App 2 - CORBA Application To Calculate & Display The Sum of Two Integers .................... 15
3. Tutorial and Revision Questions ............................................................................................................. 19

IUGET/2021-2022/BSc/300/DISTRIBUTED_PROGRAMMING/MODULE4 1
1 General Introduction
Java IDL is a technology for distributed objects--that is, objects interacting on different
platforms across a network. Java IDL is similar to RMI (Remote Method Invocation), which
supports distributed objects written entirely in the Java programming language. However, Java
IDL enables objects to interact regardless of whether they're written in the Java programming
language or another language such as C, C++, COBOL, or others.
It can also be defined as a generic term for a language that lets a program or object written
in one language communicate with another program written in an unknown language.
In distributed object technology, it's important that new objects be able to be sent to any platform
environment and discover how to run in that environment. An Object Request Broker (ORB) is an
example of a program that would use an IDL to "broker" communication between one object
program and another one.
An IDL works by requiring that a program's interfaces be described in a stub or slight extension of
the program that is compiled into it. The stubs in each program are used by a broker program to
allow them to communicate.
In software development, Java Interface Definition Language (JIDL) is an implementation of the
CORBA specification and enables interoperability and connectivity with heterogeneous objects.

1.1 Recall on Java Interfaces

In object-oriented programming, objects define their interaction with the outside world
through the methods that they expose. Those methods form the object's interface with the outside
world; for example, the buttons on the front of your television set are the interface between you
and the electrical wiring on the other side of its plastic casing, so you can press the "power" button
to turn the television on and off.
In its most common form, an interface is a group of related methods with empty bodies. For
example, a bicycle's behavior, if specified as an interface, might appear as follows:
interface Bicycle {

void changeCadence(int newValue);

void changeGear(int newValue);

void speedUp(int increment);

void applyBrakes(int decrement);

IUGET/2021-2022/BSc/300/DISTRIBUTED_PROGRAMMING/MODULE4 2
}
interface Addition{
double add(double a, double b);
};

To implement this interface, the name of the class would change (to ACMEBicycle, for example),
and the implements keyword would be used in the class declaration:
An interface is similar to a class in the following ways −
• An interface can contain any number of methods.
• An interface is written in a file with a .java extension, with the name of the interface
matching the name of the file.
• The byte code of an interface appears in a .class file.
• Interfaces appear in packages, and their corresponding bytecode file must be in a directory
structure that matches the package name.
However, an interface is different from a class in several ways, including −
• You cannot instantiate an interface.
• An interface does not contain any constructors.
• All of the methods in an interface are abstract.
• An interface cannot contain instance fields. The only fields that can appear in an interface
must be declared both static and final.
• An interface is not extended by a class; it is implemented by a class.
• An interface can extend multiple interfaces.
interface Animal {
public void eat();
public void travel();
}
public class MammalInt implements Animal {

public void eat() {

System.out.println("Mammal eats");
}

public void travel() {

System.out.println("Mammal travels");
}

public int noOfLegs() {

return 0;
}

IUGET/2021-2022/BSc/300/DISTRIBUTED_PROGRAMMING/MODULE4 3
 public static void main(String args[]) {
MammalInt m = new MammalInt();
m.eat();
m.travel();
}
}

Implementing an interface allows a class to become more formal about the behavior it promises to
provide. Interfaces form a contract between the class and the outside world, and this contract is
enforced at build time by the compiler. If your class claims to implement an interface, all methods
defined by that interface must appear in its source code before the class will successfully compile.
An interface definition completely defines the interface of an object and fully specifies each
operation’s parameters. Interfaces help providing the information needed to develop clients that
use the interface’s operations.

2. Common Object Request Brokerage Architecture (CORBA)

CORBA is an industry-standard distributed object model. A key feature of CORBA is IDL,
a language-neutral Interface Definition Language. Each language that supports CORBA has its
own IDL mapping--and as its name implies, Java IDL supports the mapping for Java. CORBA and
the IDL mappings are the work of an industry consortium known as the OMG, or Object
Management Group. Sun is a founding member of the OMG, and the Java IDL team has played
an active role in defining the IDL-to-Java mapping.
To support interaction between objects in separate programs, Java IDL provides an Object Request
Broker, or ORB.
The ORB is a class library that enables low-level communication between Java IDL
applications and other CORBA-compliant applications.
The CORBA standard describes IDL language mappings for various programming languages. It
is an industry standard that has been around since 1991; it defines how applications can
communicate with one another no matter where they are located, or what programming language
they are written in. Before Java, creating CORBA-based objects was a difficult and time-
consuming process. With Java, much of the pain associated with it has been limited or removed
altogether. Along with Java's simplicity and elegance, the CORBA framework gives your
applications the underlying machinery necessary to produce large-scale.

IUGET/2021-2022/BSc/300/DISTRIBUTED_PROGRAMMING/MODULE4 4
CORBA is the world's leading middleware solution enabling the exchange of information,
independent of hardware platforms, programming languages, and operating systems. CORBA is
essentially a design specification for an Object Request Broker (ORB), where an ORB provides
the mechanism required for distributed objects to communicate with one another, whether locally
or on remote devices, written in different languages, or at different locations on a network.
CORBA is often described as a "software bus" because it is a software-based communications
interface through which objects are located and accessed. The illustration below identifies the
primary components seen within a CORBA implementation.

Figure 1 CORBA Architecture

Data communication from client to server is accomplished through a well-defined object-oriented

interface. The Object Request Broker (ORB) determines the location of the target object, sends a
request to that object, and returns any response back to the caller. Through this object-oriented
technology, developers can take advantage of features such as inheritance, encapsulation,
polymorphism, and runtime dynamic binding. These features allow applications to be changed,
modified and re-used with minimal changes to the parent interface. The illustration below
identifies how a client sends a request to a server through the ORB:

IUGET/2021-2022/BSc/300/DISTRIBUTED_PROGRAMMING/MODULE4 5
 Figure 2 Client-Server Communication Under the CORBA

2.0 Major Components That Make Up The CORBA Architecture

➢ The Interface Definition Language, which is how CORBA interfaces are defined;
➢ The Object Request Broker (ORB), which is responsible for handling all interactions
between remote objects and the applications that use them;
➢ The Naming Service, a standard service in CORBA that lets remote clients find remote
objects on the network; and the inter-ORB communication that handles the low-level
communication between processes in a CORBA context.

2.1 Interface Definition Language (IDL)

The IDL approach separates the interface part of program code from the implementation
part. This is very significant for distributed systems because these are two types of concern that
should ideally be treated in different ways.

An IDL is designed to be programming language-independent, that is, it defines the interface of a

component only in terms of the names of methods and the parameter types that are passed in and
out of the method, regardless of whether the method is implemented in C++, C#, Java, or some

IUGET/2021-2022/BSc/300/DISTRIBUTED_PROGRAMMING/MODULE4 6
other language. An IDL explicitly identifies the type and direction of each parameter. The type
values supported are the same in general as most languages and include int, float, double, bool,
and string.

After defining an interface in IDL, the interface definition is used as input to an IDL compiler that
produces output to be compiled and linked with an object implementation and its clients.

2.1.1 IDL, Interfaces And Implementations

It is important to note that IDL is a declarative language. This means that neither objects
implementing interfaces specified in IDL nor client objects implementing the functionality to
access those interfaces are programmed in IDL. Once again, IDL only describes the way in which
an object can communicate with other objects, also providing this way the information needed to
develop clients that use the operations exposed by the interface.

The implementation of the interfaces of an object and the implementation of client objects meant
to call the operations exposed by those interfaces is achieved by developing them in a
programming language for which mappings from IDL have been defined. The mapping of an IDL
concept to a client language construct will depend on the facilities available in the client language.
For example, an IDL exception might be mapped to a structure in a language that has no notion of
exception, or to an exception in a language that does.

2.2 Object Request Broker (ORB)

The Object Request Broker (ORB) is middleware that uses the CORBA specification. The
Object Request Broker or ORB takes care of all of the details involved in routing a request from
client to object, and routing the response to its destination.
The core of the CORBA architecture is the Object Request Broker, as shown in Figure below.
Each machine involved in a CORBA application must have an ORB running in order for processes
on that machine to interact with CORBA objects running in remote processes. Object clients and
servers make requests through their ORBs; the ORB is responsible for making the requests happen
or indicating why they cannot. The client ORB provides a stub for a remote object. Requests made
on the stub are transferred from the client's ORB to the ORB servicing the implementation of the
target object. The request is passed onto the implementation through its skeleton interface.

IUGET/2021-2022/BSc/300/DISTRIBUTED_PROGRAMMING/MODULE4 7
 Figure 3 – Object Request Broker Communication

2.3 The Naming Service

The CORBA Naming Service provides a directory naming structure for remote objects.
The tree always starts with a root node, and subnodes of the object tree can be defined. Actual
objects are stored by name at the leaves of the tree. Figure 4 below depicts an example set of
objects[2] registered within a Naming Service directory. The fully qualified name of an object in
the directory is the ordered list of all of its parent nodes, starting from the root node and including
the leaf name of the object itself. So, the full name of the object labeled "Fred" is "living thing,"
"animal," "man," "Fred," in that order.

Figure 4 CORBA Naming Service

IUGET/2021-2022/BSc/300/DISTRIBUTED_PROGRAMMING/MODULE4 8
Each branch in the directory tree is called a naming context, and leaf objects have bindings to
specific names. The org.omg.CosNaming.NamingContext interface represents each branch in the
naming directory. Each NamingContext can be asked to find an object within its branch of the tree
by giving its name relative to that naming context. You can get a reference to the root context of
the naming directory from an ORB using the resolve_initial_references() method. The standard
name for the Naming Service is "NameService", so the following code snippet gets the root
NamingContext:

ORB myORB = ORB.init(...);

org.omg.CORBA.Object nameRef = myORB.resolve_initial_references("NameService");
NamingContext nc = NamingContextHelper.narrow(nameRef);

Note that we have to narrow the Object reference to a NamingContext reference using the
NamingContextHelper.narrow() method. Even though Java has a cast operation in its syntax,
there's no guarantee in the Java IDL binding that the object reference returned by the
resolve_initial_references() method is the correct type, since there's no guarantee that the local
environment has access to the language-specific definition of the object's interface.

2.4 Steps To Develop A CORBA Application

The CORBA application development process has seven phases:
1. Design and write the object interfaces.
2. Generate stubs and skeletons, and other required support classes.
3. Write the server object implementations.
4. Use the client-side Java compiler to compile both the Java code that you have written, and
the Java classes that were generated by the IDL compiler. Generate a JAR file to contain
the classes and any other resource files that are needed.
5. Publish a name for the directly-accessible objects with the CosNaming service, so you can
access them from the client program.
6. Write the client side of the application. This is the code that will run outside of the Oracle8i
data server, on a workstation or PC.
7. Compile the client code using the JDK Java compiler.
8. Load the compiled classes into the Oracle8i database, using the loadjava tool and
specifying the JAR file as its argument. Make sure to include all generated classes, such as

IUGET/2021-2022/BSc/300/DISTRIBUTED_PROGRAMMING/MODULE4 9
 stubs and skeletons. (Stubs are required in the server when the server object acts as a client
to another CORBA object.)
2.4.1 App 1 - CORBA Application To Display A Message
Here, we shall demonstrate how to create a simple application in CORBA EchoApp which will
display a message LEARNING CORBA using Java.
1. Create the IDL file
The IDL file defines the interface that will be used by the client and server for communicating and
passing objects.
When the IDL file gets compiled, it will produce a number of files, known as the stub and skeleton:
• The stub is used by the client to communicate with the server
• The skeleton is used by the server to communicate with the client
• The stub and skeleton communicate with the ORB server to facilitate the remote procedure
call
The module in the IDL file will correspond to the package and directory in which the Java code
will be generated
Echo.idl
module EchoApp {
interface Echo {
string echoString();
};
};
Module here is the name of the app that will be generated by the idl tool.

2. Generate the stub and skeleton code

There is an idlj program that comes with the JDK for generating the stub and skeleton code in
Java. Open CMD and execute the code below.

IUGET/2021-2022/BSc/300/DISTRIBUTED_PROGRAMMING/MODULE4 10
idlj -fall Echo.idl

The following files and a new package called EchoApp are generated by the idlj
program:
• _EchoStub.java
• Echo.java
• EchoHelper.java
• EchoHolder.java
• EchoOperations.java
• EchoPOA.java

Figure 5 – Generating The Stub and

Skeleton For App 1
3. Write the server code
The server program will inherit from the EchoPOA class (in order words, the Server
Implementation class will extend the POA class) that was generated as part of the idlj program.
The …POA class implements the EchoOperations interface. This interface contains the methods
we defined in the Echo.idl file, but standardized to Java.
We create an EchoServer.java class that extends the abstract EchoPoa class and then implement
the methods contained in it It’s in this class that the actions will be performed.
import EchoApp.EchoPOA;

public class EchoServer extends EchoPOA {

@Override
public String echoString() {
return "LEARNING CORBA!!!!!!!";
}
}

We create a main method in Server.java to communicate with the object request broker (ORB),
registering the server with the ORB so clients are able to find it.

IUGET/2021-2022/BSc/300/DISTRIBUTED_PROGRAMMING/MODULE4 11
import EchoApp.Echo;
import EchoApp.EchoHelper;
import org.omg.CORBA.ORB;
import org.omg.CosNaming.NameComponent;
import org.omg.CosNaming.NamingContextExt;
import org.omg.CosNaming.NamingContextExtHelper;
import org.omg.PortableServer.POA;
import org.omg.PortableServer.POAHelper;

public class Server {

public static void main(String args[]) {
try{
// create and initialize the ORB
ORB orb = ORB.init(args, null);

// get reference to rootpoa & activate the POAManager

POA rootpoa = POAHelper.narrow(orb.resolve_initial_references("RootPOA"));
rootpoa.the_POAManager().activate();

// create servant
EchoServer server = new EchoServer();

// get object reference from the servant

org.omg.CORBA.Object ref = rootpoa.servant_to_reference(server);
Echo href = EchoHelper.narrow(ref);

org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService");

NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);

NameComponent path[] = ncRef.to_name( "ECHO-SERVER" );

ncRef.rebind(path, href);

System.out.println("Server ready and waiting ...");

// wait for invocations from clients

orb.run();
}
catch (Exception e) {
System.err.println("ERROR: " + e);
e.printStackTrace(System.out);
}
System.out.println("Exiting ...");
}
}
4. Create the client program
The client program Client.java needs to get a reference to the ORB then resolve the name of the
server object it would like to invoke.

This is ECHO-SERVER in this case

After getting an instance of a Server object from the server, it can invoke methods on it just like a
method within its own JVM.

IUGET/2021-2022/BSc/300/DISTRIBUTED_PROGRAMMING/MODULE4 12
import EchoApp.Echo;
import EchoApp.EchoHelper;
import org.omg.CORBA.ORB;
import org.omg.CORBA.ORBPackage.InvalidName;
import org.omg.CosNaming.NamingContextExt;
import org.omg.CosNaming.NamingContextExtHelper;
import org.omg.CosNaming.NamingContextPackage.CannotProceed;
import org.omg.CosNaming.NamingContextPackage.NotFound;

public class Client {

public static void main(String args[]) {

try {
// create and initialize the ORB
ORB orb = ORB.init(args, null);
org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService");
NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);
Echo href = EchoHelper.narrow(ncRef.resolve_str("ECHO-SERVER"));

String hello = href.echoString();

System.out.println(hello);
} catch (InvalidName invalidName) {
invalidName.printStackTrace();
} catch (CannotProceed cannotProceed) {
cannotProceed.printStackTrace();
} catch (org.omg.CosNaming.NamingContextPackage.InvalidName
invalidName) {
invalidName.printStackTrace();
} catch (NotFound notFound) {
notFound.printStackTrace();
}
}
}

5. Compile the code

1. Compile the stub and skeleton from the directory that contains the IDL file.
javac EchoApp\*.java

IUGET/2021-2022/BSc/300/DISTRIBUTED_PROGRAMMING/MODULE4 13
 2. Generate a JAR file from the compiled stub and skeleton.
jar cvf echoapp.jar EchoApp\*.class

3. Compile the Server, EchoServer and Client classes

javac Server.java
javac Client.java
javac EchoServer.java or
javac *.java

6. Running the application

1. Start the ORB server
orbd -ORBInitialPort 1050 -ORBInitialHost localhost

2. Start the server application

java Server -ORBInitialPort 1050 -ORBInitialHost localhost

3. Start the client application

java Client -ORBInitialPort 1050 -ORBInitialHost localhost

Note: You cannot start the Server and Client using java Server or java Client
respectively. If you do, you’ll have a network Exception. You MUST start the ORB Server
first, the start your Server.

IUGET/2021-2022/BSc/300/DISTRIBUTED_PROGRAMMING/MODULE4 14
Recall On The Steps:
1. Create your IDL file. It should end with .idl
2. Using the idlj tool, generate the stub and skeleton. Usage: idlj -fall idlFile.idl
3. Write the Server Code
4. Write your Server Implemetation code that extends the abstract POA class.
5. Write the Client code
6. Compile the stub and skeleton directory using javac dir\*.java
7. Generate the jar file for the stub and skeleton using jar cvf appName.jar dir\*.class
8. Compile your Server, Server Implementation and Client classes using javac *.java
9. Start the ORB server using orbd -ORBInitialPort 1050 -ORBInitialHost localhost
10. Start your Server using java Server -ORBInitialPort 1050 -ORBInitialHost localhost
11. Start your Client using java Client -ORBInitialPort 1050 -ORBInitialHost localhost

2.4.2 App 2 - CORBA Application To Calculate & Display The Sum of Two Integers
We’ll call our app AdditionApp.

Step 1: We create our IDL.

module AdditionApp
{
interface Addition
{
long add(in long a,in long b);
};
};

Step 2: We generate the stub and skeleton using idlj -fall Addition.idl
Step 3: We create the AdditionServerImplementation class which extends the ..POA class that was
generated by the idlj tool.

import AdditionApp.*;
import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;
import org.omg.CORBA.*;
import org.omg.PortableServer.*;
import org.omg.PortableServer.POA;
import java.util.Properties;
class AdditionServerImplementation extends AdditionPOA {

IUGET/2021-2022/BSc/300/DISTRIBUTED_PROGRAMMING/MODULE4 15
 private ORB orb;
public void setORB(ORB orb_val) {
orb = orb_val;
}
// implement add() method
public int add(int a, int b) {
int r=a+b;
return r;
}
}

Step 4: We create the AdditionServer Class which will start the server.
import AdditionApp.*;
import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;
import org.omg.CORBA.*;
import org.omg.PortableServer.*;
import org.omg.PortableServer.POA;
import java.util.Properties;

public class AdditionServer {

public static void main(String args[]) {

try{
// create and initialize the ORB //// get reference to rootpoa & activate the POAManager
ORB orb = ORB.init(args, null);
POA rootpoa = POAHelper.narrow(orb.resolve_initial_references("RootPOA"));
rootpoa.the_POAManager().activate();

// create servant and register it with the ORB

AdditionServerImplementation addobj = new AdditionServerImplementation();
addobj.setORB(orb);

// get object reference from the servant

org.omg.CORBA.Object ref = rootpoa.servant_to_reference(addobj);
Addition href = AdditionHelper.narrow(ref);

org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService");

NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);

NameComponent path[] = ncRef.to_name( "ABC" );

ncRef.rebind(path, href);

System.out.println("Addition Server Started Now");

IUGET/2021-2022/BSc/300/DISTRIBUTED_PROGRAMMING/MODULE4 16
 // wait for invocations from clients
for (;;){
orb.run();
}
}
catch (Exception e) {
System.err.println("ERROR: " + e);
e.printStackTrace(System.out);
}

System.out.println("Server Exiting ...");

}
}

Step 5: We create the AdditionClient app.

import AdditionApp.*;
import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;
import org.omg.CORBA.*;
import java.io.*;
import java.util.*;

public class AdditionClient {

/**
* @param args the command line arguments
*/
public static void main(String[] args) {
try {
ORB orb = ORB.init(args, null);
org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService");
NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);
Addition addobj = (Addition) AdditionHelper.narrow(ncRef.resolve_str("ABC"));

Scanner c=new Scanner(System.in);

System.out.println("APP 2 - SIMPLE CORBA PROGRAM TO ADD 2 INTEGERS:");
for(;;){
System.out.println("Enter N1:");
String aa = c.nextLine();
System.out.println("Enter N2:");
String bb = c.nextLine();

int a=Integer.parseInt(aa);
int b=Integer.parseInt(bb);

IUGET/2021-2022/BSc/300/DISTRIBUTED_PROGRAMMING/MODULE4 17
 int sum = addobj.add(a,b);
System.out.println("SUM : "+sum);
System.out.println("-----------------------------------");
}
}
catch (Exception e) {
System.out.println("Client exception: " + e);
e.printStackTrace();
}
}
}

Step 6: We generate the stub and skeleton

Step 7: We generate the jar file
Step 8: We compile the Server, Server Implementation and the Client.
Step 9: We start the ORB Server
Step 10: We start the AdditionServer
Step 11: We start the Additionclient

The final output can be seen on the screenshot below

IUGET/2021-2022/BSc/300/DISTRIBUTED_PROGRAMMING/MODULE4 18
3. Tutorial and Revision Questions
1. Explain The Reason for Implementing A CORBA Application With Multi-threading.
2. Does CORBA Supports Asynchronous Communication? Justify your answer.
3. Can CORBA Applications Have Call Back? Explain.
4. Explain The Reasons To Avoid The Development Of Multi-threaded CORBA Application.
5. Of what use is CORBA ?
6. Explain How Can CORBA Can Allow Servers To Cause Client-Side Events.
7. What Is The Reason To Implement CORBA In Client Application?
8. How Can A CORBA Application Be Tuned For Better Performance?
9. Are There Important Forms Of Asynchronous Communication That Are Not Supported
Directly By CORBA? Justify your response.
10. What Are The Roles Of A Skeleton And A Stub In CORBA?
11. What Is The Purpose Of IDL?
12. What Is The Purpose Of Mapping?
13. What Are The Similarities Between RMI and CORBA?
14. What Are The Differences Between RMI and CORBA?
15. What Is The Purpose Of A Middleware System?
16. What Does Java Offer CORBA Programmers?
17. Which Protocol Is Used For Invoking Methods On CORBA Objects Over The Internet?
18. Explain Naming Service in CORBA?
19. Using an example in Java, Explain an Object Implementation as defined in ORB
Architecture.
20. Explain what OMG IDL is in detail.
21. How Does CORBA Support Interoperability?
22. Create a CORBA app that receives a number from the user and displays its factorial.

IUGET/2021-2022/BSc/300/DISTRIBUTED_PROGRAMMING/MODULE4 19