Frequently Asked Questions
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.
|700 MHz Intel Pentium III
|360 MHz Sun UltraSPARC IIi
|294 MHz MIPS R5900
- 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.