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.
