Architectural Considerations with Distributed Computing.

We understand distributed systems as a collection of distributed computation resources that work together as one harmonious system. It is the great achievement of computer networks, data communication and small but powerful computers that make it possible to use distributed commodity computers to facilitate distributed applications, to achieve reliable or high performance computing. The IT industry has been witnessing distributed computing progress from homogenous system to heterogeneous systems, with the scale evolving from LAN to WAN and then to Internet/Intranet. On the other hand, the increasing number and scale of IT applications have been posting new challenges to the academic field. Software approaches to distributed computing include client/server model, middle-ware components, agents, etc. System approaches include LAN, WAN, PVM (Geist et al, 1994), Cluster (Pfister, 1998), etc. While distributed computing at the system level has used open architectures for a long time, it remains immature in this respect on the software side. New distributed applications should follow open architectural standard to survive a longer time, and architectural considerations should be studied in the academic and engineering fields. Instead of initiating a universal architecture for IT applications, too ambitious a task for a single group to achieve, we will first discuss some technologies that have been used in distributed computing based on our own experience. Through the advantages and disadvantages analyses of these technologies, we can have a better understanding toward architectural considerations in the networking environment. Then we will discuss distributed computing in the open networking environment (ONE), in which we are interested in studying the possible high performance, scalable and secure applications with inter-operable architecture. Here we have three applications from previous works: a distributed MIS for post pivot (referred to as system1), a distributed component system for telecommunication management network (referred to as system2) and a dynamic stock information system over the Internet (referred to as system3). System1 has a client/server computation model with distributed databases. We had to build our distributed database system out of some commercial RDBMS products that support client/server computing but do not have distributed architecture themselves. That means the application software has to take care of many issues that come with distributed databases. Adopting distributed database architecture was for practical reasons. It turns out later that the software becomes very complex. Another lesson is that client/server is a simple solution for distributed computing over the network. However, it can be an obstacle to inter-operability and scalability because of explicit I/Os and ad hoc application protocols, if the system is directly built on low level networking facilities such as sockets. Software components have been developed to address such kind of problems as well as for the reuse purpose. The communication middle-ware in system2 is an example of successful software components. Besides the functional independence requirement, architectural consideration is so important that it is the only guarantee that a component can be integrated into the target applications easily. What's more, there seams always a conflict between the ideas of software components and