Middleware Technologies Notes

BITS Pilani - Middleware Technologies

Important Information

  • Attendance requires continuous session participation and interaction with the professor.
  • Active response to professor's queries is crucial.

Text Books

  • T1: Letha Hughes Etzkorn - Introduction to middleware _ web services, object components, and cloud computing- Chapman and Hall_CRC (2017).
  • T2: William Grosso - Java RMI (Designing & Building Distributed Applications)
  • R1: Gregor Hohpe, Bobby Woolf - Enterprise Integration Patterns_ Designing, Building, and Deploying Messaging Solutions -Addison-Wesley Professional (2003)
  • R2: MongoDB in Action
  • Students are encouraged to explore books and case studies relevant to the Indian IT industry.

Modular Structure

  • M1: Introduction and Evolution
  • M2: Enterprise Middleware
  • M3: Middleware Design and Patterns
  • M4: Middleware for Web-based Application and Cloud-based Applications
  • M5: Specialized Middleware

Middleware Overview

  • Middleware is a layer between the OS and distributed applications.
  • It abstracts the complexity and heterogeneity of distributed systems.
  • It bridges the gap between low-level OS communications and high-level programming language abstractions.
  • It provides a common programming abstraction and infrastructure for distributed applications.
  • Definition: Software that connects software components or enterprise applications in a distributed system.
    • Examples: Enterprise Application Integration software, telecommunications software, transaction monitors, and messaging-and-queueing software.

Middleware Support

  • Naming, Location, Service discovery, Replication
  • Protocol handling, Communication faults, QoS
  • Synchronization, Concurrency, Transactions, Storage
  • Access control, Authentication

Middleware Dimensions

  • Request/Reply vs. Asynchronous Messaging
  • Language-specific vs. Language-independent
  • Proprietary vs. Standards-based
  • Small-scale vs. Large-scale
  • Tightly-coupled vs. Loosely-coupled components

Common Forms of Middleware

  • Sockets
  • Remote Procedure Calls (RPC)
  • Distributed Object Oriented Components (e.g., ORB)
  • Message Oriented Middleware (Message Queues/ Enterprise Message Bus etc.)
  • Service Oriented Architectures (SOA)
  • Web services (Arbitrary / RESTful)
  • SQL-oriented data access
  • Embedded middleware
  • Cloud Computing

Sockets

  • An internal endpoint for sending/receiving data within a node on a network.
  • Berkeley/POSIX sockets defined API for Inter Process Communication (IPC) within same host (BSD 4.2 – circa 1983).
  • Early form of Middleware (limited to same host systems).
  • Windows variant (WinSock) based on BSD Sockets.
  • Treated similar to files in BSD/POSIX.
  • Maintained in File Descriptor table.
  • Supported protocols:
    • TCP/IP
    • IPv4, IPv6
    • UDP

Socket API

  • socket: creates a descriptor for use in network communications
  • bind: bind a local IP address and protocol port to a socket
  • listen: set the socket listening on the given address and port for connections from the client and set the number of incoming connections from a client (backlog) that will be allowed in the listen queue at any one time
  • accept: accept the next incoming connection (server)
  • connect: connect to a remote peer (client)
  • read: acquire incoming data from a connection
  • write: send outgoing data across a connection
  • close: terminate communication and deallocate a descriptor
  • recv: receive the next incoming datagram
  • recvmsg: receive the next incoming datagram (variation of recv)
  • recvfrom: receive the next incoming datagram and record its source endpoint address
  • send: send an outgoing datagram
  • sendmsg: send an outgoing datagram (variation of send)
  • sendto: send an outgoing datagram, usually to a prerecorded endpoint address
  • shutdown: terminate a TCP connection in one or both directions
  • getpeername: after a connection arrives, obtain the remote machine’s endpoint address from a socket
  • getsockopt: obtain the current options for a socket
  • setsockopt: change the options for a socket

Socket Life Cycle

  • TCP Client:
    • socket()
    • connect()
    • write() (data request)
    • read() (data reply)
    • close() (EOF notification)
  • TCP Server:
    • socket()
    • bind()
    • listen()
    • accept() (blocks until connection from client)
    • read()
    • do something
    • write()
    • read()
    • close()

Remote Procedure Call (RPC)

  • Masks remote function calls as being local (client/server model).
  • Request/reply paradigm usually implemented with message passing in RPC service.
  • Marshalling of function parameters and return value.

Properties of RPC

  • Language-level pattern of function call (easy to understand for programmer).
  • Synchronous request/reply interaction:
    • Natural from a programming language point-of-view.
    • Matches replies to requests.
    • Built-in synchronization of requests and replies.
  • Distribution transparency (in the no-failure case):
    • Hides the complexity of a distributed system.
  • Various reliability guarantees:
    • Deals with some distributed systems aspects of failure.

Failure Modes of RPC

  • Invocation semantics supported by RPC in the light of:
    • Network and/or server congestion.
    • Client, network and/or server failure.
    • Note: DS independent failure modes.
  • RPC systems differ, many examples, local was Mayflower.
  • May be or at most once (RPC system tries once).
    • Error return – programmer may retry.
  • Exactly once (RPC system retries a few times).
    • Hard error return – some failure most likely.
    • Note that “exactly once” cannot be guaranteed.

Disadvantages of RPC

  • Synchronous request/reply interaction:
    • Tight coupling between client and server.
    • Client may block for a long time if server is loaded leads to multi-threaded programming at client.
    • Slow/failed clients may delay servers when replying multi-threading essential at servers.
  • Distribution Transparency:
    • Not possible to mask all problems.
  • RPC paradigm is not object-oriented:
    • Invoke functions on servers as opposed to methods on objects.
    • fork(...) remote call join(...)

Object-Oriented Middleware (OOM)

  • Objects can be local or remote.
  • Object references can be local or remote.
  • Remote objects have visible remote interfaces.
  • Masks remote objects as being local using proxy objects.
  • Remote method invocation.

Properties of OOM

  • Support for object-oriented programming model
    • Objects, methods, interfaces, encapsulation…
    • exceptions (were also in some RPC systems e.g. Mayflower)
  • Synchronous request/reply interaction (same as RPC).
  • Location Transparency
    • System (ORB) maps object references to locations.
  • Services comprising multiple servers are easier to build with OOM
    • RPC programming is in terms of server-interface (operation)
    • RPC system looks up server address in a location service

Java Remote Method Invocation (RMI)

  • Distributed objects in Java.
  • RMI compiler creates proxies and skeletons.
  • RMI registry used for interface lookup.
  • Entire system written in Java (single-language system).
public interface PrintService extends Remote {
 int print(Vector printJob) throws RemoteException;
}

CORBA (Common Object Request Broker Architecture)

  • Open standard by the OMG (Version 3.0).
  • Language- and platform independent Object Request Broker (ORB).
  • General Inter-ORB Protocol (GIOP) for communication.
  • Interoperable Object References (IOR) contain object location.
  • CORBA Interface Definition Language (IDL).
  • Stubs (proxies) and skeletons created by IDL compiler.
  • Dynamic remote method invocation.
  • Interface Repository: Querying existing remote interfaces.
  • Implementation Repository: Activating remote objects on demand.

CORBA IDL

  • Definition of language-independent remote interfaces
    • Language mappings to C++, Java, Smalltalk, …
    • Translation by IDL compiler
  • Type system
    • Basic types: long (32 bit), long long (64 bit), short, float, char, boolean, octet, any, …
    • Constructed types: struct, union, sequence, array, enum
    • Objects (common super type Object)
  • Parameter passing: in, out, inout
    • Basic & constructed types passed by value
    • Objects passed by reference
typedef sequence<string> Files;
interface PrintService : Server {
 void print(in Files printJob);
};

CORBA Services (selection)

  • Naming Service: Names remote object references
  • Trading Service: Attributes (properties) remote object references
  • Persistent Object Service: Implementation of persistent CORBA objects
  • Transaction Service: Making object invocation part of transactions
  • Event Service and Notification Service
    • In response to applications‘ need for asynchronous communication
    • Built above synchronous communication with push or pull options
    • Not an integrated programming model with general IDL messages

Disadvantages of OOM

  • Synchronous request/reply interaction only
    • So CORBA oneway semantics added and -
    • Asynchronous Method Invocation (AMI)
    • But implementations may not be loosely coupled
  • Distributed garbage collection
    • Releasing memory for unused remote objects
  • OOM rather static and heavy-weight
    • Bad for ubiquitous systems and embedded devices

Message-Oriented Middleware (MOM)

  • Communication using messages
  • Messages stored in message queues
  • Message servers decouple client and server
  • Various assumptions about message content

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

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

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 serialized to JMS messages
  • A JMS interface has been provided for MQ
  • pub/sub (one-to-many) - just a specification?

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?)

Web Services

  • Use well-known web standards for distributed computing
  • Communication
    • Message content expressed in XML
    • Simple Object Access Protocol (SOAP)
      • Lightweight protocol for sync/async communication
  • Service Description
    • Web Services Description Language (WSDL)
      • Interface description for web services
  • Service Discovery
    • Universal Description Discovery and Integration (UDDI)
      • Directory with web service description in WSDL

Properties of Web Services

  • Language-independent and open standard
  • SOAP offers OOM and MOM-style communication:
    • Synchronous request/reply like OOM
    • Asynchronous messaging like MOM
    • Supports internet transports (http, smtp, …)
    • Uses XML Schema for marshalling types to/from programming language types
  • WSDL says how to use a web service
    • http://api.google.com/Google Search.wsdl
  • UDDI helps to find the right web service
    • Exports SOAP API for access

Disadvantages of Web Services

  • Low-level abstraction
    • Leaves a lot to be implemented
  • Interaction patterns have to be built
    • One-to-one and request-reply provided
    • One-to-many?
    • Still synchronous service invocation, rather than notification
    • No nested/grouped invocations, transactions, …
  • No location transparency

What We Lack (as of this point in the lecture)

  • General interaction patterns
    • We have one-to-one and request-reply
    • One-to-many? many to many?
    • Notification?
    • Dynamic joining and leaving?
  • Location transparency
    • Anonymity of communicating entities
  • Support for pervasive computing
    • Data values from sensors
    • Lightweight software

Event-Based Middleware (aka Publish/Subscribe)

  • Publishers (advertise and) publish events (messages)
  • Subscribers express interest in events with subscriptions
  • Event Service notifies interested subscribers of published events
  • Events can have arbitrary content (typed) or name/value pairs

Topic-Based and Content-Based Pub/Sub

  • Event Service matches events against subscriptions
    • What do subscriptions look like?
  • Topic-Based Publish/Subscribe
    • Publishers publish events belonging to a topic or subject
    • Subscribers subscribe to a topic subscribe(PrintJobFinishedTopic, …)
  • (Topic and) Content-Based Publish/Subscribe
    • Publishers publish events belonging to topics and
    • Subscribers provide a filter based on content of events
    • subscribe(type=printjobfinished, printer=‘aspen’, …)

Properties of Publish/Subscribe

  • Asynchronous communication
    • Publishers and subscribers are loosely coupled
  • Many-to-many interaction between pubs. and subs.
    • Scalable scheme for large-scale systems
    • Publishers do not need to know subscribers, and vice-versa
    • Dynamic join and leave of pubs, subs,
  • (Topic and) Content-based pub/sub very expressive
    • Filtered information delivered only to interested parties
    • Efficient content-based routing through a broker network

Summary of Middleware

  • Middleware is an important abstraction for building distributed systems
  • Synchronous vs. asynchronous communication
  • Scalability, many-to-many communication
  • Language integration
  • Ubiquitous systems, mobile systems
  1. Remote Procedure Call
  2. Object-Oriented Middleware
  3. Message-Oriented Middleware
  4. Event-Based Middleware

CORBA - Common Object Request Broker Architecture

CORBA
  • Open standard by the OMG (Version 3.0)
  • Language- and platform independent Object Request Broker (ORB)
  • General Inter-ORB Protocol (GIOP) for communication
  • Interoperable Object References (IOR) contain object location
  • CORBA Interface Definition Language (IDL)
  • Stubs (proxies) and skeletons created by IDL compiler
  • Dynamic remote method invocation
  • Interface Repository – Querying existing remote interfaces
  • Implementation Repository – Activating remote objects on demand
CORBA IDL
  • Definition of language-independent remote interfaces
    • Language mappings to C++, Java, Smalltalk, …
    • Translation by IDL compiler
  • Type system
    • basic types: long (32 bit), long long (64 bit), short, float, char, boolean, octet, any, …
    • constructed types: struct, union, sequence, array, enum
    • objects (common super type Object)
  • Parameter passing
    • in, out, inout
    • basic & constructed types passed by value
    • objects passed by reference
typedef sequence<string> Files;
interface PrintService : Server {
 void print(in Files printJob);
 };
CORBA Services (selection)
  • Naming Service
    • Names  remote object references
  • Trading Service
    • Attributes (properties)  remote object references
  • Persistent Object Service
    • Implementation of persistent CORBA objects
  • Transaction Service
    • Making object invocation part of transactions
  • Event Service and Notification Service
    • In response to applications‘ need for asynchronous communication
    • built above synchronous communication with push or pull options
    • not an integrated programming model with general IDL messages
CORBA Definition
  • The Common Object Request Broker Architecture (CORBA) is a standard architecture for a distributed objects system.
  • CORBA is designed to allow distributed objects to interoperate in a heterogeneous environment, where objects can be implemented in different programming language and/or deployed on different platforms
CORBA vs. Java RMI
  • 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.
    • CORBA is an architecture that was developed by the Object Management Group (OMG), an industrial consortium.
CORBA Properties
  • 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.
Architecture Diagram
  • Key Components:
    • Interface Repository
    • IDL Compiler
    • Object (Servant)
    • Client
    • Object Adapter
    • ORB
Basic Workflow
  • Client looks up object via naming service
  • Naming service returns stub
  • Stub interacts with ORB over network
  • ORB finds object implementation
  • Skeleton interacts with ORB, then object implementation
CORBA Object Interface Properties
  • A distributed object is defined using a software file similar to the remote interface file in Java RMI.
  • Since CORBA is language independent, the interface is defined using a universal language with a distinct syntax, known as the CORBA Interface Definition Language (IDL).
  • The syntax of CORBA IDL is similar to Java and C++. However, object defined in a CORBA IDL file can be implemented in a large number of diverse programming languages, including C, C++, Java, COBOL, Smalltalk, Ada, Lisp, Python, and IDLScript.
  • For each of these languages, OMG has a standardized mapping from CORBA IDL to the programming language, so that a compiler can be used to process a CORBA interface to generate the proxy files needed to interface with an object implementation or an object client written in any of the CORBA-compatible languages.
Cross-language CORBA Application
  • Demonstrates interaction between a Java client and a C++ object implementation using CORBA.
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.
  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: different types of message format are defined. 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.
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
ORB Products
  • Orbix IONA
  • Borland Visibroker
  • PrismTech’s OpenFusion
  • Web Logic Enterprise from BEA
  • Ada Broker from ENST
  • Free ORBs
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.
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.
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).
  • 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.
  • Example: IOR:000000000000000d49444c3a677269643a312e3000000 00000000001000000000000004c0001000000000015756c4 72612e6475626c696e2e696f6e612e6965000009630000002 83a5c756c7472612e6475626c696e2e696f6e612e69653a67 7269643a303a3a49523a67726964003a
    • The representation consists of the character prefix “IOR:” followed by a series of hexadecimal numeric characters, each character representing 4 bits of binary data in the IOR.
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.
CORBA Naming Service Operations
  • To export a distributed object, a 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.
CORBA Object Naming Scheme
  • 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
Naming Context and Object Names
  • 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.
Object Name Syntax
  • 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 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.
Interoperable Naming Service (INS)
  • The Interoperable Naming Service (INS) 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.
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.
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.
  • 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.
Portable Object Adapter
  • There are different types of CORBA object adapters.
  • The Portable Object Adapter, or POA, is a particular type of object adapter that is defined by the CORBA specification. An object adapter that is a POA allows an object implementation to function with different ORBs, hence the word portable.
Java IDL
  • 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.
Key Java IDL Packages
  • package org.omg.CORBA – contains interfaces and classes which provides the mapping of the OMG CORBA APIs to the Java programming language
  • package org.omg.CosNaming - contains interfaces and classes which provides the naming service for Java IDL
  • org.omg.CORBA.ORB - contains interfaces and classes which provides APIs for the Object Request Broker.
Java IDL Tools

Java IDL provides a set of tools needed for developing a CORBA application:

  • idlj - the IDL-to-Java compiler (called idl2java in Java 1.2 and before)
  • orbd - a server process which provides Naming Service and other services
  • servertool – provides a command-line interface for application programmers to register/unregister an object, and startup/shutdown a server.
  • tnameserv – an olderTransient Java IDL Naming Service whose use is now discouraged.
CORBA Interface File Example (Hello.idl)
module HelloApp
{
 interface Hello
 {
 string sayHello();
 oneway void shutdown();
 };
};
Compiling the IDL File (Using Java)
  • The IDL file should be placed in a directory dedicated to the application.
  • The file is compiled using the compiler idlj using a command as follows:
    • idlj -fall Hello.idl
  • The –fall command option is necessary for the compiler to generate all the files needed.
  • In general, the files can be found in a subdirectory named <some name>App when an interface file named <some name>.idl is compiled.
  • If the compilation is successful, the following files can be found in a HelloApp subdirectory:
    • HelloOperations.java
    • Hello.java
    • HelloHelper.java
    • HelloHolder.java
    • _HelloStub.java
    • HelloPOA.java
    • These files require no modifications.
The *Operations.java File
  • There is a file HelloOperations.java found in HelloApp/ after you compiled using idlj
  • It is known as a Java operations interface in general
  • It is a Java interface file that is equivalent to the CORBA IDL interface file (Hello.idl)
  • You should look at this file to make sure that the method signatures correspond to what you expect.
HelloApp/HelloOperations.java
  • The file contains the methods specified in the original IDL file: in this case the methods sayHello( ) and shutdown().
package HelloApp;

/**
 * HelloApp/HelloOperations.java
 * Generated by the IDL-to-Java compiler (portable),
 * version "3.1" from Hello.idl
 */

public interface HelloOperations
{
 String sayHello ();
 void shutdown ();
} // interface HelloOperations
*Operations.java File
  • The signature interface file combines the characteristics of the Java operations interface (HelloOperations.java) with the characteristics of the CORBA classes that it extends.
package HelloApp;

/**
 * HelloApp/Hello.java
 * Generated by the IDL-to-Java compiler (portable),
 * version "3.1" from Hello.idl
 */

public interface Hello extends HelloOperations,
 org.omg.CORBA.Object,
 org.omg.CORBA.portable.IDLEntity
{
}
*Helper.java file
  • The Java class HelloHelper provides auxiliary functionality needed to support a CORBA object in the context of the Java language.
  • In particular, a method, narrow, allows a CORBA object reference to be cast to its corresponding type in Java, so that a CORBA object may be operated on using syntax for Java object.
*Holder.java file
  • The Java class called HelloHolder holds (contains) a reference to an object that implements the Hello interface.
  • The class is used to handle an out or an inout parameter in IDL in Java syntax
    • ( In IDL, a parameter may be declared to be out if it is an output argument, and inout if the parameter contains an input value as well as carries an