Browse Prior Art Database

Abstraction of remote operating systems

IP.com Disclosure Number: IPCOM000015157D
Original Publication Date: 2001-Aug-01
Included in the Prior Art Database: 2003-Jun-20
Document File: 3 page(s) / 54K

Publishing Venue

IBM

Abstract

Disclosed is a method for presenting access to services and resources of a remote operating system, from a local integrated development environment (IDE). Typically, application development IDEs allow programmers to work with and manipulate local programming resources, such as local HTML, Java*, C, and C++ source files. This disclosure documents a consistent and extensible means of adding access to resources that are not on the same local workstation as the IDE. Abstracting the design for remote access, and authoring a harness framework for that abstraction, offers the ability to easily snap-in addition remote access capilities such that all remote access is consistent for the end user (programmer using the IDE) and such that there is re-use among the various snapped-in tools. Consider some of the many examples of disparate tools that require accessing a remote system, each of which can be found in today's programmer IDEs: A remote file system explorer, that possibly allows direct editing of remote source files A remote command shell, allowing users to enter commands locally that are executed remotely, with local error feedback A remote job or task monitor that allows submitting and trackings jobs or processes on a remote system A database administrator tool, that allows DBAs to design and work with databases on remote systems A remote debugger for debugging applications on a remote system A remote problem determination tool that monitors applications as they run, directing filterable messages back to the local tool A tool specialized for working with a particular remote resource, such a message queues, user profiles, message files, etc. This is just a sample of the many unique tools that exist for accessing and working with remote system resources. This disclosure offers an abstraction that each of these can be mapped to. Some things common to two or more tools in any such list are:

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 27% of the total text.

Page 1 of 3

Abstraction of remote operating systems

Disclosed is a method for presenting access to services and resources of a remote operating system, from a local integrated development environment (IDE). Typically, application development IDEs allow programmers to work with and manipulate local programming resources, such as local HTML, Java*, C, and C++ source files. This disclosure documents a consistent and extensible means of adding access to resources that are not on the same local workstation as the IDE.

Abstracting the design for remote access, and authoring a harness framework for that abstraction, offers the ability to easily snap-in addition remote access capilities such that all remote access is consistent for the end user (programmer using the IDE) and such that there is re-use among the various snapped-in tools. Consider some of the many examples of disparate tools that require accessing a remote system, each of which can be found in today's programmer IDEs:

A remote file system explorer, that possibly allows direct editing of remote source files A remote command shell, allowing users to enter commands locally that are executed remotely, with local error feedback A remote job or task monitor that allows submitting and trackings jobs or processes on a remote system A database administrator tool, that allows DBAs to design and work with databases on remote systems A remote debugger for debugging applications on a remote system A remote problem determination tool that monitors applications as they run, directing filterable messages back to the local tool A tool specialized for working with a particular remote resource, such a message queues, user profiles, message files, etc.

This is just a sample of the many unique tools that exist for accessing and working with remote system resources. This disclosure offers an abstraction that each of these can be mapped to. Some things common to two or more tools in any such list are:

A means for the user to predefine a "connection" which is a unique identifier for the physical remote system. Typically this is an IP address or hostname, or an http domain name. If each tool defines their own connection, the user ends up with many connection definitions, often to the same remote system. One per tool.

A means of identifying the remote system daemon or service that will handle this particular tool's requests. This is often an IP port number, which the server side code is waiting on, or the name of a particular servlet or cgi-bin program for http requests. This is typically tool-defined, although sometimes the user is allowed to change it to handle port collision problems. Some form of tool-specific communication protocol. It might an industry standard such as JDBC or WEBDAV, or a private program-to-program protocol. Some form of filter mechanism, if the data returned from the remote system to the local tool is potentially large. For example, for a remote file system explorer, there might be suppo...