Frequently Asked Questions
General Interest
The questions below are deemed to be of somewhat general interest (although, one's mileage may vary). Somewhat more technical questions are addressed elsewhere.
- What does your company do?
- We provide tools to enable programmers to easily develop, deploy and maintain robust distributed applications. We also
perform custom development for clients.
- My firm doesn't have a programming staff. What benefit would I gain from your technologies?
-
We make available several applications that can be used to deploy robust, easy-to-configure services. For example, a small
office environment running Microsoft Windows 95/98/ME normally has no email-related server capabilities, such as SMTP and
POP3. Since the FARGOS/VISTA Object Management Environment runs on Microsoft Windows 95/98/ME (among other supported platforms), the HTTP, SMTP and POP3, NNTP and other FARGOS/VISTA-based
services can be utilized on that platform, thus yielding an intra-office email system.
- I haven't written many programs before. How can I learn to use FARGOS/VISTA?
-
For beginning programmers, we recommend the tutorial document "Introduction
to Programming Using OIL2". Experienced programmers should find the document "FARGOS/VISTA Examples" of interest.
- What benefit would I get from using your technologies if I'm building conventional applications?
- Faster development times, reduced complexity, best-of-breed algorithms, fast multithreading even on platforms lacking
support for lightweight processes, intrinsic support for symmetric multiprocessing hardware, the ability to make legacy
services available to other applications, etc.
- Isn't object-oriented stuff old hat now?
- The concepts date back to the 1960's, so by that measure object-oriented programming is old news. Depending on your
definitions, object-orientation may imply merely a separation and hiding of data structure implementation from any application
logic that access it, thus the threshhold needed to call something object-oriented can be quite low, which in turn makes it
subsceptible to lots of unsubstantiated marketing hype. What's of more interest are attributes like support for multiple
inheritance, persistence, self-describing interfaces, versioning, etc.
- Aren't you just providing another object-oriented Remote Procedure Call package?
- Absolutely not. Frankly, we believe Remote Procedure Calls (RPCs) are a fundamentally flawed paradigm for building robust
distributed applications. The RPC model attempts to provide simplified access to remote services by using what appears to be a
conventional function call. Unfortunately, the apparent benefit of reduced complexity obtained by hiding the distributed
aspects of a service actually brings with it numerous disadvantages.
- Almost everyone is utilizing an RPC paradigm. What sort of problems could it possibly have?
-
Obviously, every program gets reduced to machine instructions, so with enough added effort, some problems can be overcome. We
assert that an important consideration should be how much effort a programmer must expend to achieve a given goal. Some of
the problems include:
- No recovery if the remote server fails — since the RPC call appears as a local function, it provides similar
all-or-nothing behavior to that of an everything-is-local application. Some RPC libraries lack even the ability to
provide this assertion and make actually execute the server side of an RPC multiple times.
- Applications are logically one monolithic piece of code — the fact that pieces run on other machines is not relevant to
the design; it is merely a hidden implementation detail. There is no solution to this problem and any work required to make
an RPC-style application more robust will increase its complexity.
- Client/server roles are imposed on components — an application performs a remote procedure call to a subroutine on a
server; for the code on the server to simultaneously make requests of the client is problematic.
- There is no natural way to keep state on the server between calls — some special mechanism must be used, such as
passing state back and forth on every call.
- No natural way to issue calls in parallel — while implementations vary, any such support will be provided using
specially constrained cases, such as routines that do not return a value.
- If RPCs make services provided by a remote server appear as if they were local, what's your approach?
- Like the RPC paradigm, FARGOS/VISTA eliminates the distinction between code executed locally or remotely. Whereas the RPC
paradigm attempts to make remotely executed functions appear as if they were local, one could argue that FARGOS/VISTA makes
local services appear as if they were remote.
- Treating everything as if it were remote is a good thing?
- Absolutely. Whereas in the RPC paradigm a programmer must determine where to partition an application into local and
remotely accessible pieces, every element of a FARGOS/VISTA application is remotely accessible. Since everything is remotely
accessible, a programmer cannot make a design mistake when selecting which portions of a program to run locally or remotely.
Applications, or pieces of an application, can even migrate from one physical machine to another, even if their operating
systems or CPU achitectures are dissimilar.
- What are some benefits of active objects?
- Conventional object-oriented applications are comprised of a collection of data objects that are accessed by one or a small
number of threads running within the address space of a monolithic program. In the FARGOS/VISTA Object Management Environment,
thousands of threads can be operating simultaneously and every method invocation is performed by a separate, unique thread of
execution. FARGOS/VISTA applications are typically implemented as cooperating collections of active objects, which can be
thought of as tiny independent programs. This is one means by which the complexity of an application is greatly reduced: rather
than deal with a massive monolithic application, a programmer can focus on much smaller components that interact with each
other. These small components also yield frequent opportunities for code-reuse. In contrast to a monolithic application, which
is almost impossible to reuse in its entirety, many FARGOS/VISTA classes are readily reusable due to their single-minded focus
on doing one thing very well.
- Code reuse is a laudable goal, but rarely achieved. Programmers are usually too busy trying to get their application coded
and debugged to think about building a library for use in the future.
- Because everything in the FARGOS/VISTA environment is an object, programmers are constrained to use object-oriented design.
The drastically reduced development times give programmers the time to do more elegant initial designs and an opportunity to
extend previously written classes. In a conventional environment, a programmer might be precluded from enhancing the
functionality of an existing method because it would break the already deployed applications that make use of it. Several
aspects of the FARGOS/VISTA object model, such as the self-describing environment and reflection, permit enhancement of methods
without affecting existing applications. Support for multiple versions of a class in use simultaneously is another supported
capability.
- How can constraining a programmer be a good thing?
- The constaints imposed are analogous to those imposed by roads and stop lights: they enable the safe and efficient
deployment of applications by independent entities. The constraints imposed by the FARGOS/VISTA object model permit
applications written by separate programming teams to interact, the utilization of generic services such as persistent and
replicated objects, migration of running applications from one machine to another, etc.
- Just how fast is your proprietary threading mechanism?
-
A lot faster than native kernel threads. As a rule of thumb, FARGOS/VISTA thread creation rates are approx. 20
threads/second for each MHz of the CPU clock rate. The table below compares the worst-case FARGOS/VISTA scenario of
invoking a dynamically loaded, interpreted method vs. the best-case scenario of creating a native kernel thread which calls a
single function that does no more work than incrementing a 32-bit integer by 1. The FARGOS/VISTA test case also includes
overhead not present in the native kernel thread case (e.g., locating the target test object and validating the access
control list), so the disparity in performance would be even greater in real-world applications.
| CPU |
FARGOS/VISTA |
Native |
| 700 MHz Intel Pentium III |
18,316 threads/sec |
7142 threads/sec |
| 360 MHz Sun UltraSPARC IIi |
7194 threads/sec |
4878 threads/sec |
| 294 MHz MIPS R5900 |
2186 threads/sec |
N/A |
- What platform should I use?
- Selection of a hardware/operating system platform is an important decision that is all too often not given the though it
deserves. For machines exposed to the public Internet, security should be at the fore-front of any selection. We believe this
rules out the use of Microsoft Windows-based products, which have historically been so riddled with bugs and design flaws that
hackers can essentially break into them at will.
-
We often recommended the use of OpenBSD due to its committment to security; however,
there have been some notable deficiencies with that distribution. If you need to use high-end or obscure hardware, there is a
good chance a device driver will not be available for OpenBSD and there was no support for symmetric
multi-processing hardware until around 2004. Few commercial software vendors make their applications available for OpenBSD
and compatibility between releases is an issue that has been consistently ignored.
-
Linux enjoys wide support from several distributors and hardware vendors. It supports a
huge variety of hardware, thus there is a good chance a device driver is available for any of the hardware you need to use,
either already in the base distribution or as a module from the vendor of brand-new hardware. While originally available for
Intel x86 (and compatible) processors, Linux has been ported to a significant number alternative hardware platforms. For
example, FARGOS/VISTA Software Development Kits for the IBM System/390 and Sony PlayStation 2 are available for downloading.
-
Sun's Solaris is a robust alternative that should be applauded
for its support of almost every API ever defined for Unix, but it suffers on the device driver front. It is a good match for
hardware manufactured by Sun and Solaris is supported by many commercial software vendors. We've supported Solaris 8 and
Solaris 10 on both SPARC and Intel platforms. Solaris 11 support is under consideration, but will probably be achieved simply
as a side-effect of the release-to-release compatibility Solaris has enjoyed for the past decade.
- Microsoft Windows NT 3.51 ran on platforms other than Intel x86-compatible, but multi-platform support has become a
historical anomoly for this operating system family (although it will reappear with Windows 8's support for ARM). If you are
deploying only an Intel x86-compatible hardware platform, a Microsoft Windows variant can be used. It enjoys a wide variety of
device support, but its origins as a single-user, insecure desktop operating system are never far behind. The code quality is
remarkably poor, which leads to frequent crashes and an amazing number of flaws that can be exploited by hackers. Deployment of
a Microsoft Windows platform requires a corresponding committment to constant babysitting and engagement in a race to apply a
never-ending stream of patches before hackers succeed in an attack.
