Monday, March 17, 2008

CORBA (Common Object Request Broker Architecture)

Common Object Request Broker Architecture


The Common Object Request Broker Architecture (CORBA) is a standard defined by the Object Management Group (OMG) that enables software components written in multiple computer languages and running on multiple computers to work together. General overview
CORBA is a mechanism in software for normalizing the method-call semantics between application objects that reside either in the same address space (application) or remote address space (same host, or remote host on a network).
CORBA uses an interface description language (IDL) to specify the interfaces that objects will present to the outside world. CORBA then specifies a “mapping” from IDL to a specific implementation language like C++ or Java. Standard mappings exist for Ada, C, C++, Lisp, Smalltalk, Java, COBOL, PL/I and Python. There are also non-standard mappings for Perl, Visual Basic, Ruby, Erlang, and Tcl implemented by object request brokers (ORBs) written for those languages.
The CORBA specification dictates that there shall be an ORB through which the application interacts with other objects. In practice, the application simply initializes the ORB, and accesses an internal Object Adapter which maintains such issues as reference counting, object (& reference) instantiation policies, object lifetime policies, etc. The Object Adapter is used to register instances of the generated code classes. Generated Code Classes are the result of compiling the user IDL code which translates the high-level interface definition into an OS- and language-specific class base for use by the user application. This step is necessary in order to enforce the CORBA semantics and provide a clean user processes for interfacing with the CORBA infrastructure.
Some IDL language mappings are more hostile than others. For example, due to the very nature of Java, the IDL-Java Mapping is rather trivial and makes usage of CORBA very simple in a Java application. The C++ mapping is not trivial but accounts for all the features of CORBA, e.g. exception handling. The C-mapping is even more strange (since it's not an OO language) but it does make sense and handles the RPC semantics just fine. (Red Hat Linux delivers with the GNOME UI system, which has its IPC built on CORBA.)
A "language mapping" requires that the developer ("user" in this case) create some IDL code representing the interfaces to his objects. Typically a CORBA implementation (either an Open Source or commercial product) comes with a tool called an IDL compiler. This compiler will convert the user's IDL code into some language-specific generated code. The generated code is then compiled using a traditional compiler to create the linkable-object files required by the application. This diagram illustrates how the generated code is used within the CORBA infrastructure:

This figure illustrates the high-level paradigm for remote interprocess communications using CORBA. Issues not addressed here, but that are accounted-for in the CORBA specification include: data typing, exceptions, network protocol, communication timeouts, etc. For example: Normally the server side has the Portable Object Adapter (POA) that redirects calls either to the local servants or (to balance the load) to the other servers. Also, both server and client parts often have interceptors that are described below. Issues CORBA (and thus this figure) does not address, but that all distributed systems must address: object lifetimes, redundancy/fail-over, naming semantics (beyond a simple name), memory management, dynamic load balancing, separation of model between display/data/control semantics, etc.
In addition to providing users with a language and a platform-neutral remote procedure call specification, CORBA defines commonly needed services such as transactions and security, events, time, and other domain-specific interface models.
Key features
Objects By Reference
Objects are used in an application "by reference". This reference is either acquired though a "stringified" URI string, NameService lookup (similar to DNS), or passed-in as a method parameter during a call.
Object references are "lightweight" objects matching the interface of the "real object" (remote or local). Method calls on the reference result in subsequent calls to the ORB and blocking on the thread while waiting for a reply, success or failure. The parameters, return data (if any) , and exception data are marshaled internally by the ORB according the local language/OS mapping.
Data By Value
The CORBA Interface Definition Language provides the language/OS-neutral inter-object communication definition. CORBA Objects are passed by reference, while data (integers, doubles, structs, enums, etc) are passed by value. The combination of Objects by reference and data-by-value provides the means to enforce strong data typing while compiling clients and servers, yet preserve the flexibility inherent in the CORBA problem-space.
Objects by Value (OBV)
Apart from remote objects, the CORBA and RMI-IIOP define the concept of the OBV. The code inside the methods of these objects is executed locally by default. If the OBV has been received from the remote side, the needed code must be either a priori known for both sides or dynamically downloaded from the sender. To make this possible, the record, defining OBV, contains the Code Base that is a space separated list of URLs from where this code should be downloaded. The OBV can also have the remote methods.
The OBV's may have fields that are transferred when the OBV is transferred. These fields can be OBV's themselves, forming lists, trees or arbitrary graphs. The OBV's have a class hierarchy, including multiple inheritance and abstract classes.
CORBA Component Model (CCM)
CORBA Component Model (CCM) is an addition to the family of CORBA definitions. It was introduced with CORBA 3 and it describes a standard application framework for CORBA components. Though not dependent on "language independent Enterprise Java Beans (EJB)", it is a more general form of EJB, providing 4 component types instead of the 2 that EJB defines. It provides an abstraction of entities that can provide and accept services through well-defined named interfaces called ports.
The CCM has a component container, where software components can be deployed. The container offers a set of services that the components can use. These services include (but are not limited to) notification, authentication, persistence and transaction management. These are the most-used services any distributed system requires, and, by moving the implementation of these services from the software components to the component container, the complexity of the components is dramatically reduced.

What is DDE and why is it totally different from COM?
DDE stands for Dynamic Data Exchange. That's exactly what it does, and nothing more. It sends data between applications using Windows messages according to a documented protocol. Saying that DDE is old-fashioned and is being replaced by COM is something you see repeated parrot fashion over and over again. DDE and COM do not work in the same way and they solve different problems. Here are some points of difference:
COM is synchronous, one party makes subroutine calls into the other and must wait until the call returns. If the called component is busy the caller is blocked until it becomes free. DDE is asynchronous, a well-programmed client sends a Windows message to the server and carries on processing. Windows holds the message and sends it to the server when the server is ready to process it.
COM is complex to program but powerful. The client can manipulate objects within the server as if they belonged to the client. DDE is straightforward to implement but all it can do is transmit data. It can only control another application because the recipient can treat data as a command.
COM works well when the client creates an instance of a server object or application for its own use. Programming a continuously running server, to which clients can attach when they wish, is possible but tricky. DDE of itself is incapable of creating objects (although OLE1 used it as a transport mechanism). The essence of DDE is that clients attach to an already running server.
Applications using COM almost always need support DLLs such as the VB runtimes or MFC. Programs using DDE can be mean and lean and do not need extra support DLLs.
COM interfaces are tightly specified and contained within the software component. Some documentation is normally built into the interface. The user of a COM component knows exactly which methods are available and how to call them. DDE interfaces are specified only in external documentation.
Because of the tight interface specification, upgrading COM components can be a nightmare. With DDE the server or client can be changed independently.
COM is frequently used to communicate with a DLL in the same process space (called an in-process server). Such as server is often termed an ActiveX control and has the extension OCX. Our DDClient and DDServer Visual Basic components are in-process servers. Using DDE to communicate between components of the same application is possible but has no benefits.
COM communication with a remote machine is called DCOM (Distributed COM). If you make a DCOM call to a remote machine which does not respond, your program (or at least the thread making the call) is stuck. DCOM has a fixed built-in timeout which you cannot change. DDE with a remote machine is called NETDDE, it is used by the Hearts game and Chat which come with Windows. Timeout is controlled by the program.
Under Windows 3.1 and 9x it is possible to crash the system by badly programmed DDE, because the message queue can be filled. NT does not crash in this way, COM does not suffer from the problem at all.
DDE is totally "Bit blind", neither the client nor server can tell whether the other application is 16-bit or 32-bit. Indeed, the server cannot know whether the client is on the same computer or not. Connecting 16 to 32 bit COM components is not usually possible.
It is easy to see from the above points why a DDE server is the most widely used way of providing data obtained from any form of hardware interface. In particular:
The server can run continuously.
It will probably serve a wide range of clients but can be updated without requiring them all to be recompiled.
It is immune from the problems associated with different versions of the system DLLs on different machines.
It can be small and self-contained.
Clients cannot interfere with the running of the server by being slow or busy
DDE mechanism overview
Making the connection between a DDE server and a DDE client
DDE uses a hierarchy of three names, the SERVICE, the TOPIC and the ITEM. A DDE CONVERSATION is established using the service and topic names as a pair. It is convenient to name the pair a CHANNEL. It is roughly the equivalent of a telephone number. The item part of the name is used to identify the particular data or command being requested by the client once a conversation is established.
To establish a conversation a DDE client specifies the service/topic name pair (channel) it wishes to connect to. Windows broadcasts the request to all top level windows. The first server to accept is connected to the client and so a conversation is established.
The client may leave either the topic or the service name unspecified, or both. This is known as a WILDCONNECT. For example, if the topic name is not specified conversations may be established on all the topics supported by a server. If both are unspecified conversations may be established on all topics with all servers. It is up to the server whether to accept such a connection, and if so on what topics.
Unlike a telephone connection, any number of quite separate conversations may be in progress on the same channel, even between the same two applications. This is often done so that only one item of information or one type of command is handled by each conversation. There is no interaction at all between different conversations using the same pair of service and topic names.
Transactions within a DDE conversation
Just as the client application initiates the establishment of a conversation, it also initiates all the transactions. It can request data from the server as a once off (a REQUEST transaction), request being kept up to date about an item of data (an ADVISE or NOTIFY transaction), give commands to the server (an EXECUTE transaction) and send unsolicited data to the server (a POKE transaction). The client associates with all these transactions the item part of the identification. It informs the server of the data required by the client in a request transaction, the action to be taken by the server in an execute transaction or the data being passed to the server in a poke transaction.
It is also possible to use the item part of the name as the data itself, with the topic name indicating the context in which the data is to be used.
Raw DDE has no timing constraints except the order in which messages are sent. At the Windows message level, there is no distinction between synchronous and asynchronous transactions. Synchronous and asynchronous operation is a feature of the DDE management library, or DDEML.
To find out more go to How to get further information
Question and topic list DDE Software downloads Home page

DDE ( Dynamic Data Exchange) and OLE (Object linking and embeding)

Dynamic Data Exchange
Dynamic Data Exchange (DDE) is a technology for communication between multiple applications under Microsoft Windows or OS/2. Overview
Dynamic Data Exchange was first introduced in 1987 with the release of Windows 2.0. It used the "Windows Messaging Layer" functionality within Windows. This is the same system used by the "copy and paste" functionality. Therefore, DDE continues to work even in modern versions of Windows. Newer technology has been developed that has, to some extent, overshadowed DDE (e.g. OLE, COM, and OLE Automation), however, it is still used in several places inside Windows, e.g. for Shell file associations.
The primary function of DDE is to allow Windows applications to share data. For example, a cell in Microsoft Excel could be linked to a value in another application and when the value changed, it would be automatically updated in the Excel spreadsheet. The data communication was established by a simple, three-segment model. Each program was known to DDE by its "application" name. Each application could further organize information by groups known as "topic" and each topic could serve up individual pieces of data as an "item". For example, if a user wanted to pull a value from Microsoft Excel which was contained in a spreadsheet called "Book1.xls" in the cell in the first row and first column, the application would be "Excel", the topic "Book1.xls" and the item "r1c1".
Note: In DDE, the application, topic and item are not case-sensitive.
A common use of DDE was for custom-developed applications to control off-the-shelf software. For example, a custom in-house application might use DDE to open a Microsoft Excel spreadsheet and fill it with data, by opening a DDE conversation with Excel and sending it DDE commands. Today, however, one could also use the Excel object model with OLE Automation (part of COM).
While newer technologies like COM offer features DDE doesn't have, there are also issues with regard to configuration that can make COM more difficult to use than DDE.
[edit] NetDDE
A California-based company called Wonderware developed an extension for DDE called NetDDE that could be used to initiate and maintain the network connections needed for DDE conversations between DDE-aware applications running on different computers in a network and transparently exchange data. A DDE conversation is an interaction between client and server applications. NetDDE could be used along with DDE and the DDE management library (DDEML) in applications.
Object Linking and Embedding
Object Linking and Embedding (OLE) is a technology that allows embedding and linking to documents and other objects, developed by Microsoft. It is found on the Component Object Model. For developers, it brought OLE custom controls (OCX), a way to develop and use custom user interface elements. On a technical level, an OLE object is any object that implements the IOleObject interface, possibly along with a wide range of other interfaces, depending on the object's needs.
Overview
OLE allows an editor to "farm out" part of a document to another editor and then re-import it. For example, a desktop publishing system might send some text to a word processor or a picture to a bitmap editor using OLE. The main benefit of using OLE is to display visualizations of data from other programs that the host program is not normally able to generate itself (e.g. a pie-chart in a text document), as well to create a master file. References to data in this file can be made and the master file can then have changed data which will then take effect in the referenced document. This is called "linking" (instead of "embedding").
Its primary use is for managing compound documents, but it is also used for transferring data between different applications using drag and drop and clipboard operations. The concept of "embedding" is also central to much use of multimedia in Web pages, which tend to embed video, animation (including Flash animations), and audio files within the hypertext markup language (such as HTML or XHTML) or other structural markup language used (such as XML or SGML) — possibly, but not necessarily, using a different embedding mechanism than OLE.

Middleware Technology

Middleware Technology
Introduction

Middleware, which is quickly becoming synonymous with enterprise applications integration (EAI), is software that is invisible to the user. It takes two or more different applications and makes them work seamlessly together. This is accomplished by placing middleware between layers of software to make the layers below and on the sides work with each other (Figure 1). On that broad definition, middleware could be almost any software in a layered software stack. Further, middleware is a continually evolving term. Since much of the software business is driven through the perceptions of the “hottest” current technologies, many companies are giving their software the name “middleware” because it is popular.

Middleware, or EAI, products enable information to be shared in a seamless real-time fashion across multiple functional departments, geographies and applications. Benefits include better customer service, accurate planning and forecasting, and reduced manual re-entry and associated data inaccuracies.

Middleware is essential to migrating mainframe applications to client/server applications, or to Java or internet-protocol based applications, and to providing for communication across heterogeneous platforms. This technology began to evolve during the 1990s to provide for interoperability in support of the move to client/server architectures.[i][1] There are two primary applications for middleware using any of the above middleware initiatives: Computer Telephony and Software Interfaces such as via Java based middleware applications. In this discussion of middleware, we will explore both uses.
About the Client/Server API
The Client/Server API provides the framework for implementing servers. Servers handle resources on behalf of multiple clients. The Symbian platform itself has many servers, for example, the file server for sharing file related resources and the window server for sharing UI resources.
In specialised circumstances, users may wish to write their own server. A server defines a client interface which the client uses to request specific services. The client and server programs run in different threads and so cannot directly access each other's address space. They use a message passing protocol to communicate.
Server operating systems
Some popular operating systems for servers—such as FreeBSD, Solaris, and Linux—are derived from or similar to the UNIX operating system. UNIX was originally a minicomputer operating system, and as servers gradually replaced traditional minicomputers, UNIX was a logical and efficient choice of operating system for the servers. However, the market share of the Windows Server product line has been growing steadily, and has become the new top server operating system in revenue from sales, as of 2005.[1] However UNIX-based systems, many of which are free, are more popular.
Server-oriented operating systems tend to have certain features in common that make them more suitable for the server environment, such as the absence of a GUI (or an optional GUI); the ability to be reconfigured (in both hardware and software) to at least some extent without stopping the system; advanced backup facilities to permit online backups of critical data at regular and frequent intervals; facilities to enable the movement of data between different volumes or devices in such a way that is transparent to the end user; flexible and advanced networking capabilities; features (such as daemons in UNIX or services in Windows) that make unattended execution of programs more reliable; tight system security, with advanced user, resource, data, and memory protection, and so on. Server-oriented operating systems in many cases can interact with hardware sensors to detect conditions such as overheating, processor and disk failure, and either alert an operator, take remedial action, or both, depending on the configuration.
Because the requirements of servers are, in some cases, almost diametrically opposed to those of desktop computers, it is extremely difficult to design an operating system that handles both environments well; thus, operating systems that are well suited to the desktop may not be ideal for servers and vice versa. Regardless of OS vendor, system configurations that are ideal for servers may be unsatisfactory for desktop use, and configurations that perform well on the desktop may leave much to be desired on servers. As a result many operating systems have both a server and a desktop version released. Nevertheless, the desktop versions of Windows and the Mac OS X (also Unix-based) operating systems are used on a minority of servers, as are some proprietary mainframe operating systems, such as z/OS. The dominant operating systems among servers continues to be UNIX versions and clones.
The rise of the microprocessor-based server was facilitated by the development of several versions of Unix to run on the Intel x86 microprocessor architecture. The Microsoft Windows family of operating systems also runs on Intel hardware, and versions beginning with Windows NT have incorporated features making them suitable for use on servers.
Whilst the role of server and desktop operating systems remains distinct, improvements in both hardware performance and reliability and operating system reliability have blurred the distinction between these two classes of system, which at one point remained largely separate in terms of code base, hardware and vendor providers. Today, many desktop and server operating systems share the same code base, and differ chiefly in terms of configuration. Furthermore, the rationalisation of many corporate applications towards web-based and middleware platforms has lessened the demand for specialist application servers.
Client (computing)
or system that accesses a (remote) service on another computer system known as a server by way of a network. The term was first applied to devices that were not capable of running their own stand-alone programs, but could interact with remote computers via a network. These dumb terminals were clients of the time-sharing mainframe computer.
The client-server model is still used today on the Internet, where a user may connect to a service operating on a remote system through the internet protocol suite. Web browsers are clients that connect to web servers and retrieve web pages for display. Most people use e-mail clients to retrieve their e-mail from their internet service provider's mail storage servers. Online chat uses a variety of clients, which vary depending on the chat protocol being used. Game Clients usually refer to the software that is the game in only multiplayer online games for the computer.
Increasingly, existing large client applications are being switched to websites, making the browser a sort of universal client. This avoids the hassle of downloading a large piece of software onto any computer you want to use the application on. An example of this is the rise of webmail.
Types
Clients are generally classified as either "fat clients", "thin clients", or "hybrid clients".

Local storage
Local processing
Fat Client
Yes
Yes
Hybrid Client
No
Yes
Thin Client
No
No
Fat
A fat client (also known as a thick client or rich client) is a client that performs the bulk of any data processing operations itself, and does not necessarily rely on the server. The fat client is most common in the form of a personal computer, as the personal computers or laptops can operate independently. Programming environments for rich clients include Curl, Delphi, Droplets,.Net, Java, win32 and X11.
Thin
A thin client is a minimal sort of client. Thin clients use the resources of the host computer. A thin client's job is generally just to graphically display pictures provided by an application server, which performs the bulk of any required data processing. Programming environments for thin clients include JavaScript/AJAX (client side automation), ASP, JSP, Ruby on Rails, Python's Django, PHP and other (depends on server-side backend and uses HTML pages or rich media like Flash, Flex or Silverlight on client).
Hybrid
Main article: Hybrid client
A hybrid client is a mixture of the above two client models. Similar to a fat client, it processes locally, but relies on the server for storage data. This approach offers features from both the fat client (multimedia support, high performance) and the thin client (high manageability, flexibility)..
Network management
Network management refers to the activities, methods, procedures, and tools that pertain to the operation, administration, maintenance, and provisioning of networked systems. [1]
Operation deals with keeping the network (and the services that the network provides) up and running smoothly. It includes monitoring the network to spot problems as soon as possible, ideally before users are affected.
Administration deals with keeping track of resources in the network and how they are assigned. It includes all the "housekeeping" that is necessary to keep the network under control.
Maintenance is concerned with performing repairs and upgrades - for example, when equipment must be replaced, when a router needs a patch for an operating system image, when a new switch is added to a network. Maintenance also involves corrective and preventive measures to make the managed network run "better", such as adjusting device configuration parameters.
Provisioning is concerned with configuring resources in the network to support a given service. For example, this might include setting up the network so that a new customer can receive voice service.
Functions that are performed as part of network management accordingly include controlling, planning, allocating, deploying, coordinating, and monitoring the resources of a network, network planning, frequency allocation, predetermined traffic routing to support load balancing, cryptographic key distribution authorization, configuration management, fault management, security management, performance management, bandwidth management, and accounting management.
network management
Refers to the broad subject of managing computer networks. There exists a wide variety of software and hardware products that help network system administrators manage a network. Network management covers a wide area, including:
· Security: Ensuring that the network is protected from unauthorized users.
· Performance: Eliminating bottlenecks in the network.
· Reliability: Making sure the network is available to users and responding to hardware and software malfunctions.
Network operating system
network operating system (NOS) is a piece of software that controls a network and its message (e.g. packet) traffic and queues, controls access by multiple users to network resources such as files, and provides for certain administrative functions, including security.
Note 1: A network operating system is most frequently used with local area networks and wide area networks, but could also have application to larger network systems.
Note 2: The upper 5 layers of the OSI Reference Model provide the foundation upon which many network operating systems are based.
Source: from Federal Standard 1037C
NOS was also the name of a proprietary time-sharing operating system on the CDC 60-bit 6000 and Cyber series mainframe computers; in the mid 1980s, NOS was replaced with NOS/VE on the 64-bit Cyber-180 systems.
Network Operating System (NOS) is an operating system that includes special functions for connecting computers and devices into a local-area network (LAN) or Inter-networking. Some popular NOSs for DOS and Windows systems include Novell NetWare, Windows NT, 2000, 2003, 2008 Server, Sun Solaris and IBM OS/2. The Cisco IOS (Internet Operating System) is also a network operating system with a focus on the Internetworking capabilities of network devices.
Features
Some of the features of Network Operating System are:
Provide basic operating system features such as support for processors, protocols, automatic hardware detection and support multi-processing of applications
Security features such as authentication, authorization, logon restrictions and access control
Provide name and directory services
Provide file, print, web services, back-up and replication services
Dynamic Data Exchange
Dynamic Data Exchange (DDE) is a technology for communication between multiple applications under Microsoft Windows or OS/2. Overview
Dynamic Data Exchange was first introduced in 1987 with the release of Windows 2.0. It used the "Windows Messaging Layer" functionality within Windows. This is the same system used by the "copy and paste" functionality. Therefore, DDE continues to work even in modern versions of Windows. Newer technology has been developed that has, to some extent, overshadowed DDE (e.g. OLE, COM, and OLE Automation), however, it is still used in several places inside Windows, e.g. for Shell file associations.
The primary function of DDE is to allow Windows applications to share data. For example, a cell in Microsoft Excel could be linked to a value in another application and when the value changed, it would be automatically updated in the Excel spreadsheet. The data communication was established by a simple, three-segment model. Each program was known to DDE by its "application" name. Each application could further organize information by groups known as "topic" and each topic could serve up individual pieces of data as an "item". For example, if a user wanted to pull a value from Microsoft Excel which was contained in a spreadsheet called "Book1.xls" in the cell in the first row and first column, the application would be "Excel", the topic "Book1.xls" and the item "r1c1".
Note: In DDE, the application, topic and item are not case-sensitive.
A common use of DDE was for custom-developed applications to control off-the-shelf software. For example, a custom in-house application might use DDE to open a Microsoft Excel spreadsheet and fill it with data, by opening a DDE conversation with Excel and sending it DDE commands. Today, however, one could also use the Excel object model with OLE Automation (part of COM).
While newer technologies like COM offer features DDE doesn't have, there are also issues with regard to configuration that can make COM more difficult to use than DDE.
[edit] NetDDE
A California-based company called Wonderware developed an extension for DDE called NetDDE that could be used to initiate and maintain the network connections needed for DDE conversations between DDE-aware applications running on different computers in a network and transparently exchange data. A DDE conversation is an interaction between client and server applications. NetDDE could be used along with DDE and the DDE management library (DDEML) in applications.
Object Linking and Embedding
Object Linking and Embedding (OLE) is a technology that allows embedding and linking to documents and other objects, developed by Microsoft. It is found on the Component Object Model. For developers, it brought OLE custom controls (OCX), a way to develop and use custom user interface elements. On a technical level, an OLE object is any object that implements the IOleObject interface, possibly along with a wide range of other interfaces, depending on the object's needs.
Overview
OLE allows an editor to "farm out" part of a document to another editor and then re-import it. For example, a desktop publishing system might send some text to a word processor or a picture to a bitmap editor using OLE. The main benefit of using OLE is to display visualizations of data from other programs that the host program is not normally able to generate itself (e.g. a pie-chart in a text document), as well to create a master file. References to data in this file can be made and the master file can then have changed data which will then take effect in the referenced document. This is called "linking" (instead of "embedding").
Its primary use is for managing compound documents, but it is also used for transferring data between different applications using drag and drop and clipboard operations. The concept of "embedding" is also central to much use of multimedia in Web pages, which tend to embed video, animation (including Flash animations), and audio files within the hypertext markup language (such as HTML or XHTML) or other structural markup language used (such as XML or SGML) — possibly, but not necessarily, using a different embedding mechanism than OLE.
Common Object Request Broker Architecture
The Common Object Request Broker Architecture (CORBA) is a standard defined by the Object Management Group (OMG) that enables software components written in multiple computer languages and running on multiple computers to work together. General overview
CORBA is a mechanism in software for normalizing the method-call semantics between application objects that reside either in the same address space (application) or remote address space (same host, or remote host on a network).
CORBA uses an interface description language (IDL) to specify the interfaces that objects will present to the outside world. CORBA then specifies a “mapping” from IDL to a specific implementation language like C++ or Java. Standard mappings exist for Ada, C, C++, Lisp, Smalltalk, Java, COBOL, PL/I and Python. There are also non-standard mappings for Perl, Visual Basic, Ruby, Erlang, and Tcl implemented by object request brokers (ORBs) written for those languages.
The CORBA specification dictates that there shall be an ORB through which the application interacts with other objects. In practice, the application simply initializes the ORB, and accesses an internal Object Adapter which maintains such issues as reference counting, object (& reference) instantiation policies, object lifetime policies, etc. The Object Adapter is used to register instances of the generated code classes. Generated Code Classes are the result of compiling the user IDL code which translates the high-level interface definition into an OS- and language-specific class base for use by the user application. This step is necessary in order to enforce the CORBA semantics and provide a clean user processes for interfacing with the CORBA infrastructure.
Some IDL language mappings are more hostile than others. For example, due to the very nature of Java, the IDL-Java Mapping is rather trivial and makes usage of CORBA very simple in a Java application. The C++ mapping is not trivial but accounts for all the features of CORBA, e.g. exception handling. The C-mapping is even more strange (since it's not an OO language) but it does make sense and handles the RPC semantics just fine. (Red Hat Linux delivers with the GNOME UI system, which has its IPC built on CORBA.)
A "language mapping" requires that the developer ("user" in this case) create some IDL code representing the interfaces to his objects. Typically a CORBA implementation (either an Open Source or commercial product) comes with a tool called an IDL compiler. This compiler will convert the user's IDL code into some language-specific generated code. The generated code is then compiled using a traditional compiler to create the linkable-object files required by the application. This diagram illustrates how the generated code is used within the CORBA infrastructure:

This figure illustrates the high-level paradigm for remote interprocess communications using CORBA. Issues not addressed here, but that are accounted-for in the CORBA specification include: data typing, exceptions, network protocol, communication timeouts, etc. For example: Normally the server side has the Portable Object Adapter (POA) that redirects calls either to the local servants or (to balance the load) to the other servers. Also, both server and client parts often have interceptors that are described below. Issues CORBA (and thus this figure) does not address, but that all distributed systems must address: object lifetimes, redundancy/fail-over, naming semantics (beyond a simple name), memory management, dynamic load balancing, separation of model between display/data/control semantics, etc.
In addition to providing users with a language and a platform-neutral remote procedure call specification, CORBA defines commonly needed services such as transactions and security, events, time, and other domain-specific interface models.
Key features
Objects By Reference
Objects are used in an application "by reference". This reference is either acquired though a "stringified" URI string, NameService lookup (similar to DNS), or passed-in as a method parameter during a call.
Object references are "lightweight" objects matching the interface of the "real object" (remote or local). Method calls on the reference result in subsequent calls to the ORB and blocking on the thread while waiting for a reply, success or failure. The parameters, return data (if any) , and exception data are marshaled internally by the ORB according the local language/OS mapping.
Data By Value
The CORBA Interface Definition Language provides the language/OS-neutral inter-object communication definition. CORBA Objects are passed by reference, while data (integers, doubles, structs, enums, etc) are passed by value. The combination of Objects by reference and data-by-value provides the means to enforce strong data typing while compiling clients and servers, yet preserve the flexibility inherent in the CORBA problem-space.
Objects by Value (OBV)
Apart from remote objects, the CORBA and RMI-IIOP define the concept of the OBV. The code inside the methods of these objects is executed locally by default. If the OBV has been received from the remote side, the needed code must be either a priori known for both sides or dynamically downloaded from the sender. To make this possible, the record, defining OBV, contains the Code Base that is a space separated list of URLs from where this code should be downloaded. The OBV can also have the remote methods.
The OBV's may have fields that are transferred when the OBV is transferred. These fields can be OBV's themselves, forming lists, trees or arbitrary graphs. The OBV's have a class hierarchy, including multiple inheritance and abstract classes.
CORBA Component Model (CCM)
CORBA Component Model (CCM) is an addition to the family of CORBA definitions. It was introduced with CORBA 3 and it describes a standard application framework for CORBA components. Though not dependent on "language independent Enterprise Java Beans (EJB)", it is a more general form of EJB, providing 4 component types instead of the 2 that EJB defines. It provides an abstraction of entities that can provide and accept services through well-defined named interfaces called ports.
The CCM has a component container, where software components can be deployed. The container offers a set of services that the components can use. These services include (but are not limited to) notification, authentication, persistence and transaction management. These are the most-used services any distributed system requires, and, by moving the implementation of these services from the software components to the component container, the complexity of the components is dramatically reduced.

What is DDE and why is it totally different from COM?
DDE stands for Dynamic Data Exchange. That's exactly what it does, and nothing more. It sends data between applications using Windows messages according to a documented protocol. Saying that DDE is old-fashioned and is being replaced by COM is something you see repeated parrot fashion over and over again. DDE and COM do not work in the same way and they solve different problems. Here are some points of difference:
COM is synchronous, one party makes subroutine calls into the other and must wait until the call returns. If the called component is busy the caller is blocked until it becomes free. DDE is asynchronous, a well-programmed client sends a Windows message to the server and carries on processing. Windows holds the message and sends it to the server when the server is ready to process it.
COM is complex to program but powerful. The client can manipulate objects within the server as if they belonged to the client. DDE is straightforward to implement but all it can do is transmit data. It can only control another application because the recipient can treat data as a command.
COM works well when the client creates an instance of a server object or application for its own use. Programming a continuously running server, to which clients can attach when they wish, is possible but tricky. DDE of itself is incapable of creating objects (although OLE1 used it as a transport mechanism). The essence of DDE is that clients attach to an already running server.
Applications using COM almost always need support DLLs such as the VB runtimes or MFC. Programs using DDE can be mean and lean and do not need extra support DLLs.
COM interfaces are tightly specified and contained within the software component. Some documentation is normally built into the interface. The user of a COM component knows exactly which methods are available and how to call them. DDE interfaces are specified only in external documentation.
Because of the tight interface specification, upgrading COM components can be a nightmare. With DDE the server or client can be changed independently.
COM is frequently used to communicate with a DLL in the same process space (called an in-process server). Such as server is often termed an ActiveX control and has the extension OCX. Our DDClient and DDServer Visual Basic components are in-process servers. Using DDE to communicate between components of the same application is possible but has no benefits.
COM communication with a remote machine is called DCOM (Distributed COM). If you make a DCOM call to a remote machine which does not respond, your program (or at least the thread making the call) is stuck. DCOM has a fixed built-in timeout which you cannot change. DDE with a remote machine is called NETDDE, it is used by the Hearts game and Chat which come with Windows. Timeout is controlled by the program.
Under Windows 3.1 and 9x it is possible to crash the system by badly programmed DDE, because the message queue can be filled. NT does not crash in this way, COM does not suffer from the problem at all.
DDE is totally "Bit blind", neither the client nor server can tell whether the other application is 16-bit or 32-bit. Indeed, the server cannot know whether the client is on the same computer or not. Connecting 16 to 32 bit COM components is not usually possible.
It is easy to see from the above points why a DDE server is the most widely used way of providing data obtained from any form of hardware interface. In particular:
The server can run continuously.
It will probably serve a wide range of clients but can be updated without requiring them all to be recompiled.
It is immune from the problems associated with different versions of the system DLLs on different machines.
It can be small and self-contained.
Clients cannot interfere with the running of the server by being slow or busy
DDE mechanism overview
Making the connection between a DDE server and a DDE client
DDE uses a hierarchy of three names, the SERVICE, the TOPIC and the ITEM. A DDE CONVERSATION is established using the service and topic names as a pair. It is convenient to name the pair a CHANNEL. It is roughly the equivalent of a telephone number. The item part of the name is used to identify the particular data or command being requested by the client once a conversation is established.
To establish a conversation a DDE client specifies the service/topic name pair (channel) it wishes to connect to. Windows broadcasts the request to all top level windows. The first server to accept is connected to the client and so a conversation is established.
The client may leave either the topic or the service name unspecified, or both. This is known as a WILDCONNECT. For example, if the topic name is not specified conversations may be established on all the topics supported by a server. If both are unspecified conversations may be established on all topics with all servers. It is up to the server whether to accept such a connection, and if so on what topics.
Unlike a telephone connection, any number of quite separate conversations may be in progress on the same channel, even between the same two applications. This is often done so that only one item of information or one type of command is handled by each conversation. There is no interaction at all between different conversations using the same pair of service and topic names.
Transactions within a DDE conversation
Just as the client application initiates the establishment of a conversation, it also initiates all the transactions. It can request data from the server as a once off (a REQUEST transaction), request being kept up to date about an item of data (an ADVISE or NOTIFY transaction), give commands to the server (an EXECUTE transaction) and send unsolicited data to the server (a POKE transaction). The client associates with all these transactions the item part of the identification. It informs the server of the data required by the client in a request transaction, the action to be taken by the server in an execute transaction or the data being passed to the server in a poke transaction.
It is also possible to use the item part of the name as the data itself, with the topic name indicating the context in which the data is to be used.
Raw DDE has no timing constraints except the order in which messages are sent. At the Windows message level, there is no distinction between synchronous and asynchronous transactions. Synchronous and asynchronous operation is a feature of the DDE management library, or DDEML.
To find out more go to How to get further information
Question and topic list DDE Software downloads Home page
Network DDE (NetDDE)
DDE across a network is simple to set up. It uses NetBIOS and since this can be run over TCP/IP, NetDDE can use the Internet. Given a fast connection, network DDE is if anything faster than between two programs on one machine, because the server and client can process in parallel. In order to operate DDE over a network the following steps are necessary.
1. On both machines, a DDE agent called NETDDE.EXE must be running, its job is to transmit the data across the network. Under Windows for Workgroups and Windows 9x NETDDE.EXE can be put in the Startup Group or be started manually. Under Windows NT it is a service which is started when required.
2. On the server side only, DDE shares must be created. These bind a service/topic name pair to a share name. For example, the pair WinChat/Chat has the share name Chat$. All the share information is stored in the registry, which has a different format under 3x/9x and NT. You may read that altering the registry by hand is required on Windows 9x, but this is not true.
The Windows API NDde makes the registry entries, it has calls such as NDdeShareAdd(). Application programs can use the API to share their DDE services automatically. The user creates shares manually with the program DDESHARE.EXE, which makes the necessary API calls.
In Windows for Workgroups 3.11 and Windows 9x only a 16-bit API is provided, so DDESHARE for those systems is a 16-bit program. If you do not have this program you can get it from the the DDE download area. The display of the program is not bug free. If it gets confused, which it may after deleting a share, exit and re-run. Under Windows NT only a 32-bit NDde API is available, so the NT version of DDESHARE is a 32-bit program.
The DDE server has no knowledge of the share and does not know if its clients are local or remote.
3. The client program must be changed to use the special service/topic pair http:// , for example service "http:// " and topic "Chat$".
The client and server both hold a DDE conversation with NETDDE.EXE on the local machine. To make a connection, the client NETDDE sends the requested share name to the remote computer. The remote NETDDE agent looks in the registry for the share name. If it exists the permissions are checked. At the server end NETDDE then attempts to connect to the real service and topic names specified in the registry. The server may be started automatically. Once the conversation has been established all DDE transactions are the same as between two programs on the same machine
Graphical user interface
A graphical user interface or GUI (IPA: /ˈɡuːiː/) is a type of user interface which allows people to interact with a computer and computer-controlled devices. It presents graphical icons, visual indicators or special graphical elements called "widgets". Often the icons are used in conjunction with text, labels or text navigation to fully represent the information and actions available to a user. But instead of offering only text menus, or requiring typed commands, the actions are usually performed through direct manipulation of the graphical elements.
The term GUI is historically restricted to the scope of two-dimensional display screens with display resolutions capable of describing generic information, in the tradition of the computer science research at Palo Alto Research Center (PARC) (formerly Xerox PARC and still a subsidiary of Xerox). The term GUI does not apply to other high-resolution types of interfaces that are non-generic, such as videogames, or not restricted to flat screens, like volumetric displays.
Components
A GUI uses a combination of technologies and devices to provide a platform the user can interact with, for the tasks of gathering and producing information.
The most common combination in GUIs is the WIMP paradigm. This style of interaction uses a physical input device to control the position of a cursor and presents information organized in windows and represented with icons. Available commands are compiled together in menus and actioned through the pointing device.
In personal computers all these elements are modelled through a desktop metaphor, in which the display represents a desktop upon which documents and folders of documents can be placed. Smaller mobile devices such as PDAs and smartphones typically use the WIMP elements with different unifying metaphors, due to constraints in space and available input devices.
Applications for which WIMP is not well suited may use newer interaction techniques, collectively named as non-WIMP user interfaces.

Comparison to previous interfaces
Command line interfaces
GUIs were introduced in reaction to the steep learning curve of command line interfaces (CLI), which require commands to be typed on the keyboard. Since the commands available in command line interfaces can be numerous, complicated operations can be completed using a short sequence of words and symbols. This allows for greater efficiency and productivity once many commands are learned, but reaching this level takes some time because the command words are not easily discoverable. WIMPs ("window, icon, menu, pointing device"), on the other hand, present the user with numerous widgets that represent and can trigger some of the system's available commands.
WIMPs extensively use modes as the meaning of all keys and clicks on specific positions on the screen are redefined all the time. Command line interfaces use modes only in limited forms, such as the current directory and environment variables.
Most modern operating systems provide both a GUI and some level of a CLI, although the GUIs usually receive more attention. The GUI is usually WIMP-based, although occasionally other metaphors surface, such as those used in Microsoft Bob, 3dwm or File System Visualizer (FSV).
Applications may also provide both interfaces, and when they do the GUI is usually a WIMP wrapper around the command-line version. This is especially common with applications designed for Unix-like operating systems. The latter used to be implemented first because it allowed the developers to focus exclusively on their product's functionality without bothering about interface details such as designing icons and placing buttons. Designing programs this way also allows users to run the program non-interactively, such as in a shell script.
Text user interfaces
Text user interfaces (TUI) share with GUIs their use of the entire screen area and exposure of available commands through widgets like form entry and menus. However, TUIs only use text and symbols available on a typical text terminal, while GUIs typically use high resolution graphics modes. This allows the GUI to present more detailed information and fine-grained direct manipulation.
Remote administration
From Wikipedia, the free encyclopedia
Jump to: navigation, search
Remote administration refers to any method of controlling a computer from a remote location.
Software that allows remote administration is becoming increasingly common and is often used when it is difficult or impractical to be physically near a system in order to use it, or in order to access web material that is not available in one's location, for example viewing the BBC iPlayer from outside the United Kingdom.
Requirements
Internet connection
Any computer with an Internet connection, TCP/IP or on a Local Area Network can be remotely administered.
For non-malicious administration, the user must install or enable server software on the host system in order to be viewed. Then the user/client can access the host system from another computer using the installed software.
Usually, both systems should be connected to the internet, and the IP address of the host/server system must be known. Remote administration is therefore less practical if the host uses a dial-up modem, which is not constantly online and often has a Dynamic IP.
Connecting
When the client connects to the host computer, a window showing the Desktop of the host usually appears. The client may then control the host as if he/she were sitting right in front of it.
Certain versions of Windows XP have a built-in remote administration package called Remote Desktop Connection. A free cross-platform alternative is VNC, which offers similar functionality.
Common tasks for which remote administration is used
Shutdown
Shutting down or rebooting another computer over a network
Modifying
Editing another computer's registry settings
Modifying system services
Installing software on another machine
Modifying logical groups
Viewing
Remotely assisting others
Supervising computer or internet usage
Access to a remote system's "Computer Management" snap-in
General
Controlling one's own computer from a remote location (e.g. to access the software on a personal computer from an internet café).
Popular software
Windows
Windows Server 2003/2008, Windows XP, Windows XP Media Center and Tablet PC Editions, and Windows Vista Ultimate, Enterprise and Business editions come with Microsoft's Remote Desktop client.
Windows Server 2003 comes with built-in remote administration tools, including a web application and a simplified version of Terminal Services designed for Remote administration.
Active Directory and other features found in Microsoft's Windows NT Domains allow for remote administration of computers that are members of the domain, including editing the registry and modifying system services and access to the system's "Computer Management" Microsoft Management Console snap-in.
Non-Windows
VNC can be used for remote administration of computers, however it is increasingly being used as an equivalent of Terminal Services and Remote Desktop Protocol for multi-user environments.
Back Orifice, whilst commonly used as a Script Kiddie tool, claims to be a remote-administration and system management tool. Critics have previously stated that the capabilities of the software require a very loose definition of what "administration" entails.
Linux, UNIX and BSD support remote administration via remote login, typically via SSH (The use of the Telnet protocol has been phased out due to security concerns). X-server connection forwarding, often tunnelled over SSH for security, allows GUI programs to be used remotely. VNC is also available for these operating systems.
Apple Remote Desktop provides Macintosh users with remote administration capabilities.
Radmin (Famatech Remote Administrator) is also a widely used tool for remote administration with features such as secure password authentication, file sharing, remote shutdown and high frame rate transfers.
Scriptlogic's Desktop Authority encompasses remote control as a part of remote management. This solution includes: secure web-based access to client machines, real-time diagnostics and troubleshooting, management of the file system, users/groups, registry, virtual memory, reboots and more - without user interaction, interactive remote monitoring and control of the desktop, supports clients running Windows 98 through XP/2003/Vista.
Wireless Remote Administration
Remote administration software has recently started to appear on wireless devices such as the BlackBerry, Pocket PC, and Palm devices, as well as some mobile phones.
Generally these solutions do not provide the full remote access seen on software such as VNC or Terminal Services, but do allow administrators to perform a variety of tasks, such as rebooting computers, resetting passwords, and viewing system event logs, thus reducing or even eliminating the need for system administrators to carry a laptop or be within reach of the office.

Types of Server

Types of Server
A Server is a computer or device on a network that manages network resources. For example, a file server is a computer and storage device dedicated to storing files Any user on the network can store files on the server. A print server is a computer that manages one or more printers and a network server is a computer that manages network traffic.Servers are often dedicated, meaning that they perform no other tasks besides their server tasks. On multiprocessing operating systems however, a single computer can execute several programs at once. A server in this case could refer to the program that is managing resources rather than the entire computer.What is Server Platform?A term often used synonymously with operating system. A platform is the underlying hardware or software for a system and is thus the engine that drives the server.
Server types:Application ServersSometimes referred to as a type of middleware, application servers occupy a large chunk of computing territory between database servers and the end user, and they often connect the two.Middleware is a software that connects two otherwise separate applications For example, there are a number of middleware products that link a database system to a Web server This allows users to request data from the database using forms displayed on a Web browser and it enables the Web server to return dynamic Web pages based on the user's requests and profile.The term middleware is used to describe separate products that serve as the glue between two applications. It is, therefore, distinct from import and export features that may be built into one of the applications. Middleware is sometimes called plumbing because it connects two sides of an application and passes data between them. Common middleware categories include:
* TP monitors* DCE environments* RPC systems* Object Request Brokers (ORBs)* Database access systems* Message Passing
Audio/Video ServersAudio/Video servers bring multimedia capabilities to Web sites by enabling them to broadcast streaming multimedia content. Streaming is a technique for transferring data such that it can be processed as a steady and continuous stream. Streaming technologies are becoming increasingly important with the growth of the Internet because most users do not have fast enough access to download large multimedia files quickly. With streaming, the client browser or plug-in can starts displaying the data before the entire file has been transmitted.For streaming to work, the client side receiving the data must be able to collect the data and send it as a steady stream to the application that is processing the data and converting it to sound or pictures. This means that if the streaming client receives the data more quickly than required, it needs to save the excess data in a buffer If the data doesn't come quickly enough, however, the presentation of the data will not be smooth.There are a number of competing streaming technologies emerging. For audio data on the Internet, the de facto standard is Progressive Network's RealAudio.Chat ServersChat servers enable a large number of users to exchange information in an environment similar to Internet newsgroups that offer real-time discussion capabilities. Real time means occurring immediately. The term is used to describe a number of different computer features. For example, real-time operating systems are systems that respond to input immediately. They are used for such tasks as navigation, in which the computer must react to a steady flow of new information without interruption. Most general-purpose operating systems are not real-time because they can take a few seconds, or even minutes, to react.Real time can also refer to events simulated by a computer at the same speed that they would occur in real life. In graphics animation, for example, a real-time program would display objects moving across the screen at the same speed that they would actually move.Fax ServersA fax server is an ideal solution for organizations looking to reduce incoming and outgoing telephone resources but that need to fax actual documents.FTP ServersOne of the oldest of the Internet services, File Transfer Protocol makes it possible to move one or more files securely between computers while providing file security and organization as well as transfer control.Groupware ServersA GroupWare server is software designed to enable users to collaborate, regardless of location, via the Internet or a corporate Intranet and to work together in a virtual atmosphere.IRC ServersAn option for those seeking real-time capabilities, Internet Relay Chat consists of various separate networks (or "nets") of servers that allow users to connect to each other via an IRC network.List ServersList servers offer a way to better manage mailing lists, whether they are interactive discussions open to the public or one-way lists that deliver announcements, newsletters, or advertising.Mail ServersAlmost as ubiquitous and crucial as Web servers, mail servers move and store mail over corporate networks via LANs and WANs and across the Internet.News ServersNews servers act as a distribution and delivery source for the thousands of public news groups currently accessible over the USENET news network. USENET is a worldwide bulletin board system that can be accessed through the Internet or through many online services The USENET contains more than 14,000 forums called newsgroups that cover every imaginable interest group. It is used daily by millions of people around the world.Proxy ServersProxy servers sit between a client program typically a Web browser and an external server (typically another server on the Web) to filter requests, improve performance, and share connections.Telnet ServersA Telnet server enables users to log on to a host computer and perform tasks as if they're working on the remote computer itself.Web ServersAt its core, a Web server serves static content to a Web browser by loading a file from a disk and serving it across the network to a user's Web browser. The browser and server talking to each other using HTTP mediate this entire exchange.

IPC ( Inter process communication )

Inter-Process Communication - Part 1
By Hiran Ramankutty
Scope
The purpose of this article is to get the readers familiar with the different mechanisms that are available for communicating between two or more processes. This may also serve as a tutorial for the novice programmer. There might be several good tutorials on this subject, but here I will try to communicate my explorations of this subject. This article may not be technically perfect. Please send your suggestions and queries to .
Introduction
Inter-Process Communication, which in short is known as IPC, deals mainly with the techniques and mechanisms that facilitate communication between processes. Now, why do we need special separate mechanisms or techniques for communicating between processes? Why isn't it possible to have information shared between two processes without using such special mechanisms?
Let us start from something primitive. Imagine you have two glasses completely filled with water. One glass contains hot water and the other contains cold water. What can you do to make the temperature of water in both the glasses equal? The simplest answer will be to mix the water from both the glasses in a glass with much bigger capacity. Once water is mixed, the temperature becomes equal after some time. If one can remember, this will be framed as a problem with some numerical data in a High-School Physics examination. If we go by principles, then the phenomenon here is conduction. If we go by our topic of IPC, then we can say that since the two glasses were full, we had to use another glass with a larger capacity to mix the contents in order to balance their heat energy.
Have you ever wondered about the communication medium used in telephones? What about the blood transporting system in the human body which communicates blood to different parts of the body? What about my fingers which are typing this document? My brain is doing so many things at a time. How is it directing one of my fingers to hit one key and some other finger to hit another key? How is it synchronizing the typing work that is done by both my hands? How is it also directing me to type the letters of a word that are actually coming to my mind?
Don't worry. I am not going to give a class in Biology. But it would be good if one can imagine a few more situations where we are using inter-process communication, though not necessarily in the human body or in a computer program.
So, where are we now? We know that some medium or other is required for communication between different processes. Similarly, when it comes to computer programs, we need some mechanism or medium for communication. Primarily, processes can use the available memory to communicate with each other. But then, the memory is completely managed by the operating system. A process will be allotted some part of the available memory for execution. Then each process will have its own unique user space. In no way will the memory allotted for one process overlap with the memory allotted for another process. Imagine what would happen otherwise!
So, now the question - how do different processes with unique address space communicate with each other? The operating system's kernel, which has access to all the memory available, will act as the communication channel. Similar to our earlier example, where the glass with hot water is one process address space, the glass with cold water is another, and the glass with the larger capacity is the kernel address space, so that we pour both hot water and cold water into the glass with larger capacity.
What next? There are different IPC mechanisms which come into use based on the different requirements. In terms of our water glasses, we can determine the specifics of both pouring the water into the larger glass and how it will be used after beign poured.
Basic IPC
OK, enough of glasses and water. The IPC mechanisms can be classified into the following categories as given below:
pipes
fifos
shared memory
mapped memory
message queues
sockets


Pipes:

Pipes were evolved in the most primitive forms of the Unix operating system. They provide unidirectional flow of communication between processes within the same system. In other words, they are half-duplex, that is, data flows in only one direction. A pipe is created by invoking the pipe system call, which creates a pair of file descriptors. These descriptors point to a pipe inode and the file descriptors are returned through the filedes argument. In the file descriptor pair, filedes[0] is used for reading whereas filedes[1] is used for writing.
Let me explain a scenario where we can use the pipe system call: consider a keyboard-reader program which simply exits after any alpha-numeric character is pressed on the keyboard. We will create two processes; one of them will read characters from the keyboard, and the other will continuously check for alpha-numeric characters.

Save and compile the program as cc filename.c -lpthread. Run the program and check the results. Try hitting a different key every time.
The read_char function simply reads a character other than '\n' from the keyboard and writes it to filedes[1]. We have the thread check_hit, which continuously checks for the character in filedes[0]. If the character in filedes[0] is an alpha-numeric character, then the character is printed and the program terminates.
One major feature of pipe is that the data flowing through the communication medium is transient, that is, data once read from the read descriptor cannot be read again. Also, if we write data continuously into the write descriptor, then we will be able to read the data only in the order in which the data was written. One can experiment with that by doing successive writes or reads to the respective descriptors.
So, what happens when the pipe system call is invoked? A good look at the manual entry for pipe suggests that it creates a pair of file descriptors. This suggests that the kernel implements pipe within the file system. However, pipe does not actually exist as such - so when the call is made, the kernel allocates free inodes and creates a pair of file descriptors as well as the corresponding entries in the file table which the kernel uses. Hence, the kernel enables the user to use the normal file operations like read, write, etc., which the user does through the file descriptors. The kernel makes sure that one of the descriptors is for reading and another one if for writing.
I am not going to go into the details of the pipe implementation on the kernel side. For further reading, one can refer the books mentioned at the end of this article.
FIFOs
FIFOs (first in, first out) are similar to the working of pipes. FIFOs also provide half-duplex flow of data just like pipes. The difference between fifos and pipes is that the former is identified in the file system with a name, while the latter is not. That is, fifos are named pipes. Fifos are identified by an access point which is a file within the file system, whereas pipes are identified by an access point which is simply an allotted inode. Another major difference between fifos and pipes is that fifos last throughout the life-cycle of the system, while pipes last only during the life-cycle of the process in which they were created. To make it more clear, fifos exist beyond the life of the process. Since they are identified by the file system, they remain in the hierarchy until explicitly removed using unlink, but pipes are inherited only by related processes, that is, processes which are descendants of a single process.
Shared Memory
Shared Memory is one of the three kinds of System V IPC mechanism which enables different processes to communicate with each other as if these processes shared the virtual address space; hence, any process sharing the memory region can read or write to it. One can imagine some part of memory being set aside for use by different processes.
The System V IPC describes the use of the shared memory mechanism as consisting of four steps. Taken in order, they are:
Fetching an identifier for the shared memory area - shmget (shared memory get)
Using the identifier to get the shared memory address - shmat (shared memory attach),
Detaching the shared memory area after use - shmdt (shared memory detach) and
Finally using the address to control accesses, permissions, receive information and destroy the shared memory area - shmctl (shared memory control).

Inter-process communication

Inter-process communication

Inter-Process Communication (IPC) is a set of techniques for the exchange of data among two or more threads in one or more processes. Processes may be running on one or more computers connected by a network. IPC techniques are divided into methods for message passing, synchronization, shared memory, and remote procedure calls (RPC). The method of IPC used may vary based on the bandwidth and latency of communication between the threads, and the type of data being communicated.
IPC may also be referred to as inter-thread communication and inter-application communication.
IPC, on pair with the address space concept, is the foundation for address space independence/isolation

Inter-process communication (IPC) is a set of interfaces, which is usually programmed in other for a programmer to communicate between a series of processes. This allows the running of programs concurrently in an operating system.
There are quite a number of methods used in inter-process communications. They are:

q Pipes: This allows the flow of data in one direction only. Data from the output is usually buffered until the input process receives it which must have a common origin. In computer programming, especially in Unix operating systems, a pipe is a technique for passing information from one program process to another. Unlike other forms of interprocess communication (IPC), a pipe is one-way communication only. Basically, a pipe passes a parameter such as the output of one process to another process which accepts it as input. The system temporarily holds the piped information until it is read by the receiving process.
Using a UNIX shell (the UNIX interactive command interface), a pipe is specified in a command line as a simple vertical bar () between two command sequences. The output or result of the first command sequence is used as the input to the second command sequence. The pipe system call is used in a similar way within a program.
For two-way communication between processes, two pipes can be set up, one for each direction. A limitation of pipes for interprocess communication is that the processes using pipes must have a common parent process (that is, share a common open or initiation process and exist as the result of a fork system call from a parent process).


q Named Pipes: This is a pipe with a specific name. It can be used in processes that do not have a shared common process origin. Example is FIFO where the data is written to a pipe is first named. In computer programming, a named pipe is a method for passing information from one computer process to other processes using a pipe or message holding place that is given a specific name. Unlike a regular pipe, a named pipe can be used by processes that do not have to share a common process origin and the message sent to the named pipe can be read by any authorized process that knows the name of the named pipe.
A named pipe is sometimes called a "FIFO" (first in, first out) because the first data written to the pipe is the first data that is read from it.

q Message queuing: This allows messages to be passed between messages using either a single queue or several message queues. This is managed by the system kernel. These messages are co-ordinated using an application program interface (API) in programming, message queueing is a method by which process (or program instances) can exchange or pass data using an interface to a system-managed queue of messages. Messages can vary in length and be assigned different types or usages. A message queue can be created by one process and used by multiple processes that read and/or write messages to the queue. For example, a server process can read and write messages from and to a message queue created for client processes. The message type can be used to associate a message with a particular client process even though all messages are on the same queue.
The message queue is managed by the operating system (or kernel). Application programs (or their processes) create message queues and send and receive messages using an application program interface (API). In Unix systems, the C programming language msgget function is used with various parameters specifying the action requested, message queue ID, message type, and so forth.
The maximum size of a message in a queue is limited by the operating system and is typically 8,192 bytes.
q Semaphores: This is used in solving problems associated with synchronization and avoiding race conditions. They are integers values which are greater than or equal to zero In programming, especially in Unix systems, semaphores are a technique for coordinating or synchronizing activities in which multiple processes compete for the same operating system resources. A semaphore is a value in a designated place in operating system (or kernel) storage that each process can check and then change. Depending on the value that is found, the process can use the resource or will find that it is already in use and must wait for some period before trying again. Semaphores can be binary (0 or 1) or can have additional values. Typically, a process using semaphores checks the value and then, if it using the resource, changes the value to reflect this so that subsequent semaphore users will know to wait.
Semaphores are commonly use for two purposes: to share a common memory space and to share access to files. Semaphores are one of the techniques for interprocess communication (IPC). The C programming language provides a set of interfaces or "functions" for managing semaphores.
q Shared Memory: This allows the interchange of data through a defined area of memory. Semaphore value has to be obtained before data can get access to shared memory. In computer programming, shared memory is a method by which program processes can exchange data more quickly than by reading and writing using the regular operating system services. For example, a client process may have data to pass to a server process that the server process is to modify and return to the client. Ordinarily, this would require the client writing to an output file (using the buffers of the operating system) and the server then reading that file as input from the buffers to its own work space. Using a designated area of shared memory, the data can be made directly accessible to both processes without having to use the system services. To put the data in shared memory, the client gets access to shared memory after checking a semaphore value, writes the data, and then resets the semaphore to signal to the server (which periodically checks shared memory for possible input) that data is waiting. In turn, the server process writes data back to the shared memory area, using the semaphore to indicate that data is ready to be read.

q Sockets: This method is mostly used to communicate over a network, between a client and a server. It allows for a standard connection which I computer and operating system independent. Sockets is a method for communication between a client program and a server program in a network. A socket is defined as "the endpoint in a connection." Sockets are created and used with a set of programming requests or "function calls" sometimes called the sockets application programming interface (API). The most common sockets API is the Berkeley Unix C interface for sockets. Sockets can also be used for communication between processes within the same computer.
This is the typical sequence of sockets requests from a server application in the "connectionless" context of the Internet in which a server handles many client requests and does not maintain a connection longer than the serving of the immediate request:
socket()bind()recvfrom()(wait for a sendto request from some client)(process the sendto request)sendto (in reply to the request from the client...for example, send an HTML file)
A corresponding client sequence of sockets requests would be:
socket()bind()sendto()recvfrom()
Sockets can also be used for "connection-oriented" transactions with a somewhat different sequence of C language system calls or functions.

Mutual exclusion processes has a shortcoming which is the fact that it wastes the processor time.
There are primitive interprocesses that block instead of wasting the processor time.
Some of these are:

Sleep and Wakeup

SLEEP is a system call that causes the caller to block, that is, be suspended until another process wakes it up. The WAKEUP call has one parameter, the process to be awakened.

The Producer-Consumer Problem

In this case, two processes share a common, fixed-size buffer. One of the processes puts information into the buffer, and the other one, the consumer, takes it out. This could be easy with 3 or more processes in which one wakeup waiting bit is insufficient, another patch could be made, and a second wakeup waiting bit is added of 8 or 32 but the problem of race condition will still be there.

Events Counter

This involves programming a program without requiring mutual exclusion. Event counters value can only increase and never decrease. There are three operations defined on an event counter for example, E:
1. Read (E): Return value of E

2. Advance (E): Atomically increment E by 1.

3. Await (E, v): Wait until E has a value of v or more.

Two events counters are used. The first one, in would be to count the cumulative number of items that the producer discussed above has put into the buffer since the program started running. The other one out, counts the cumulative number of items that the consumer has removed from the buffer so far. Therefore, it is clear that in must be greater than or equal to out, but not more that the size of the buffer. This is method that works with pipes discussed above.

Monitors
This is about the best way of achieving mutual exclusion.
A Monitor is a collection of procedures, variables, and data structures that are grouped together in a special kind of module or package. The monitor uses the wait and signal. The "WAIT" is to indicate to the other process that the buffer is full and so causes the calling process to block and allows the process that was earlier prohibited to enter the process at this point. "SIGNAL" will allow the other process to be awakened by the process that entered during the "WAIT".

OSI model

The Open Systems Interconnection Basic Reference Model (OSI Reference Model or OSI Model for short) is a layered, abstract description for communications and computer network protocol design. It was developed as part of the Open Systems Interconnection (OSI) initiative and is sometimes known as the OSI seven layer model. From top to bottom, the OSI Model consists of the Application, Presentation, Session, Transport, Network, Data Link, and Physical layers. A layer is a collection of related functions that provides services to the layer above it and receives service from the layer below it. For example, a layer that provides error-free communications across a network provides the path needed by applications above it, while it calls the next lower layer to send and receive packets that make up the contents of the path.
Even though newer IETF, IEEE, and indeed OSI protocol work subsequent to the publication of the original architectural standards that have largely superseded it, the OSI model is an excellent place to begin the study of network architecture. Not understanding that the pure seven-layer model is more historic than current, many beginners make the mistake of trying to fit every protocol they study into one of the seven basic layers. This is not always easy to do as many of the protocols in use on the Internet today were designed as part of the TCP/IP model, and may not fit cleanly into the OSI model.

History

In 1977, work on a layered model of network architecture, which was to become the OSI model, started in the American National Standards Institute (ANSI) working group on Distributed Systems (DISY).[1] With the DISY work and worldwide input, the International Organization for Standardization (ISO) began to develop its OSI networking suite. [2] According to Bachman, the term "OSI" came into use on 12 October 1979. OSI has two major components: an abstract model of networking (the Basic Reference Model, or seven-layer model) and a set of concrete protocols. The standard documents that describe OSI can be downloaded from ISO or ITU-T[citation needed].
Parts of OSI have influenced Internet protocol development, but none more than the abstract model itself, documented in ISO 7498 and its various agenda. In this model, a networking system is divided into layers. Within each layer, one or more entities implement its functionality. Each entity interacts directly only with the layer immediately beneath it, and provides facilities for use by the layer above it.
In particular, Internet protocols are deliberately not as rigorously designed as the OSI model, but a common version of the TCP/IP model splits it into four layers. The Internet Application Layer includes the OSI Application Layer, Presentation Layer, and most of the Session Layer. Its End-to-End Layer includes the graceful close function of the OSI Session Layer as well as the Transport Layer. Its Internetwork Layer is equivalent to the OSI Network Layer, while its Interface layer includes the OSI Data Link and Physical Layers. These comparisons are based on the original seven-layer protocol model as defined in ISO 7498, rather than refinements in such things as the Internal Organization of the Network Layer document.
Protocols enable an entity in one host to interact with a corresponding entity at the same layer in a remote host. Service definitions abstractly describe the functionality provided to an (N)-layer by an (N-1) layer, where N is one of the seven layers inside the local host.

Description of OSI layers

Layer 7: Application layer
Main article: Application layer
This application layer interfaces directly to and performs application services for the application processes; it also issues requests to the presentation layer. Note carefully that this layer provides services to user-defined application processes, and not to the end user. For example, it defines a file transfer protocol, but the end user must go through an application process to invoke file transfer. The OSI model does not include human interfaces. The common application services sublayer provides functional elements including the Remote Operations Service Element (comparable to Internet Remote Procedure Call), Association Control, and Transaction Processing (according to the ACID requirements).
Above the common application service sublayer are functions meaningful to user application programs, such as messaging (X.400), directory (X.500), file transfer (FTAM), virtual terminal (VTAM), and batch job manipulation (JTAM). These contrast with user applications that use the services of the application layer, but are not part of the application layer itself.
File Transfer applications using FTAM (OSI protocol) or FTP (TCP/IP Protocol)
Mail Transfer clients using X.400 (OSI protocol) or SMTP/POP3/IMAP (TCP/IP protocols)
Web browsers using HTTP (TCP/IP protocol); no true OSI protocol for web applications
Layer 6: Presentation layer
Main article: Presentation layer
The presentation layer establishes a context between application layer entities, in which the higher-layer entities can use different syntax and semantics, as long as the Presentation Service understands both and the mapping between them. The presentation service data units are then encapsulated into Session Protocol Data Units, and moved down the stack.
The original presentation structure used the Basic Encoding Rules of Abstract Syntax Notation One (ASN.1), with capabilities such as converting an EBCDIC-coded text file to an ASCII-coded file, or serializing objects and other data structures into and out of XML. ASN.1 has a set of cryptographic encoding rules that allows end-to-end encryption between application entities.
Layer 5: Session layer
Main article: Session layer
The session layer controls the dialogues/connections (sessions) between computers. It establishes, manages and terminates the connections between the local and remote application. It provides for full-duplex, half-duplex, or simplex operation, and establishes checkpointing, adjournment, termination, and restart procedures. The OSI model made this layer responsible for "graceful close" of sessions, which is a property of TCP, and also for session checkpointing and recovery, which is not usually used in the Internet protocols suite. Session layers are commonly used in application environments that make use of remote procedure calls (RPCs).
iSCSI, which implements the Small Computer Systems Interface (SCSI) encapsulated into TCP/IP packets, is a session layer protocol increasingly used in Storage Area Networks and internally between processors and high-performance storage devices. iSCSI uses TCP for guaranteed delivery, and carries SCSI command descriptor blocks (CDB) as payload to create a virtual SCSI bus between iSCSI initiators and iSCSI targets.
Layer 4: Transport layer
Main article: Transport layer
The transport layer provides transparent transfer of data between end users, providing reliable data transfer services to the upper layers. The transport layer controls the reliability of a given link through flow control, segmentation/desegmentation, and error control. Some protocols are state and connection oriented. This means that the transport layer can keep track of the segments and retransmit those that fail.
Although it was not developed under the OSI Reference Model and does not strictly conform to the OSI definition of the Transport layer, the best known examples of a layer 4 protocol are the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).
Of the actual OSI protocols, there are five classes of transport protocols ranging from class 0 (which is also known as TP0 and provides the least error recovery) to class 4 (which is also known as TP4 and is designed for less reliable networks, similar to the Internet). Class 4 is closest to TCP, although TCP contains functions, such as the graceful close, which OSI assigns to the Session Layer.
Perhaps an easy way to visualize the transport layer is to compare it with a Post Office, which deals with the dispatch and classification of mail and parcels sent. Do remember, however, that a post office manages the outer envelope of mail. Higher layers may have the equivalent of double envelopes, such as cryptographic presentation services that can be read by the addressee only. Roughly speaking, tunneling protocols operate at the transport layer, such as carrying non-IP protocols such as IBM's SNA or Novell's IPX over an IP network, or end-to-end encryption with IPsec. While Generic Routing Encapsulation (GRE) might seem to be a network layer protocol, if the encapsulation of the payload takes place only at endpoint, GRE becomes closer to a transport protocol that uses IP headers but contains complete frames or packets to deliver to an endpoint. L2TP carries PPP frames inside transport packets.
Layer 3: Network layer
Main article: Network layer
The network layer provides the functional and procedural means of transferring variable length data sequences from a source to a destination via one or more networks while maintaining the quality of service requested by the Transport layer. The Network layer performs network routing functions, and might also perform fragmentation and reassembly, and report delivery errors. Routers operate at this layer—sending data throughout the extended network and making the Internet possible. This is a logical addressing scheme – values are chosen by the network engineer. The addressing scheme is hierarchical.
The best-known example of a layer 3 protocol is the Internet Protocol (IP). It manages the connectionless transfer of data one hop at a time, from end system to ingress router, to router to router, and from egress router to destination end system. It is not responsible for reliable delivery to a next hop, but only for the detection of errored packets so they may be discarded. When the medium of the next hop cannot accept a packet in its current length, IP is responsible for fragmenting into sufficiently small packets that the medium can accept it.
A number of layer management protocols, a function defined in the Management Annex, ISO 7498/4, belong to the network layer. These include routing protocols, multicast group management, network layer information and error, and network layer address assignment. It is the function of the payload that makes these belong to the network layer, not the protocol that carries them.
Layer 2: Data Link layer
Main article: Data link layer
The data link layer provides the functional and procedural means to transfer data between network entities and to detect and possibly correct errors that may occur in the physical layer. Originally, this layer was intended for point-to-point and point-to-multipoint media, characteristic of wide area media in the telephone system. Local area network architecture, which included broadcast-capable multiaccess media, was developed independently of the ISO work, in IEEE Project 802. IEEE work assumed sublayering and management functions not required for WAN use. In modern practice, only error detection, not flow control using sliding window, is present in modern data link protocols such as Point-to-Point Protocol (PPP), and, on local area networks, the IEEE 802.2 LLC layer is not used for most protocols on Ethernet, and, on other local area networks, its flow control and acknowledgment mechanisms are rarely used. Sliding window flow control and acknowledgment is used at the transport layers by protocols such as TCP, but is still used in niches where X.25 offers performance advantages.
Both WAN and LAN services arrange bits, from the physical layer, into logical sequences called frames. Not all physical layer bits necessarily go into frames, as some of these bits are purely intended for physical layer functions. For example, every fifth bit of the FDDI bit stream is not used by the data link layer.
WAN Protocol Architecture
Connection-oriented WAN data link protocols, in addition to framing, detect and may correct errors. They also are capable of controlling the rate of transmission. A WAN data link layer might implement a sliding window flow control and acknowledgment mechanism to provide reliable delivery of frames; that is the case for SDLC and HDLC, and derivatives of HDLC such as LAPB and LAPD.
IEEE 802 LAN Architecture
Practical, connectionless LANs began with the pre-IEEE Ethernet specification, which is the ancestor of IEEE 802.3. This layer manages the interaction of devices with a shared medium, which is the function of a Media Access Control sublayer. Above this MAC sublayer is the media-independent IEEE 802.2 Logical Link Control (LLC) sublayer, which deals with addressing and multiplexing on multiaccess media.
While IEEE 802.3 is the dominant wired LAN protocol and IEEE 802.11 the wireless LAN protocol, obsolescent MAC layers include Token Ring and FDDI. The MAC sublayer detects but does not correct errors.
Layer 1: Physical layer
Main article: Physical layer
The physical layer defines all the electrical and physical specifications for devices. In particular, it defines the relationship between a device and a physical medium. This includes the layout of pins, voltages, cable specifications, Hubs, repeaters, network adapters, Host Bus Adapters (HBAs used in Storage Area Networks) and more.
To understand the function of the physical layer in contrast to the functions of the data link layer, think of the physical layer as concerned primarily with the interaction of a single device with a medium, where the data link layer is concerned more with the interactions of multiple devices (i.e., at least two) with a shared medium. The physical layer will tell one device how to transmit to the medium, and another device how to receive from it (in most cases it does not tell the device how to connect to the medium). Obsolescent physical layer standards such as RS-232 do use physical wires to control access to the medium.
The major functions and services performed by the physical layer are:
Establishment and termination of a connection to a communications medium.
Participation in the process whereby the communication resources are effectively shared among multiple users. For example, contention resolution and flow control.
Modulation, or conversion between the representation of digital data in user equipment and the corresponding signals transmitted over a communications channel. These are signals operating over the physical cabling (such as copper and optical fiber) or over a radio link.
Parallel SCSI buses operate in this layer, although it must be remembered that the logical SCSI protocol is a transport-layer protocol that runs over this bus. Various physical-layer Ethernet standards are also in this layer; Ethernet incorporates both this layer and the data-link layer. The same applies to other local-area networks, such as Token ring, FDDI, and IEEE 802.11, as well as personal area networks such as Bluetooth and IEEE 802.15.4.
Interfaces
Neither the OSI Reference Model nor OSI protocols specify any programming interfaces, other than as deliberately abstract service specifications. Protocol specifications precisely define the interfaces between different computers, but the software interfaces inside computers are implementation-specific.
For example, Microsoft Windows' Winsock, and Unix's Berkeley sockets and System V Transport Layer Interface, are interfaces between applications (layers 5 and above) and the transport (layer 4). NDIS and ODI are interfaces between the media (layer 2) and the network protocol (layer 3).