DISTRIBUTED SYSTEMS ARCHITECTURE

DISTRIBUTED SYSTEMS ARCHITECTURE

Week 2 Print Distributed Systems Architecture – Software The organization of a distributed system is as simple or complex as the number of systems, services, or applications being executed and shared across nodes and locations, both internal and external. The software architecture depicts the structure, configuration, and management of software and tools synchronized with the operating system and how they interact across the network and with other nodes. One of the core goals or objectives of a distributed systems architecture is to segregate applications in a separate layer from the user interface, databases, operating systems, and tools. This segregation across nodes paves the way for faster and improved performance in the execution of applications.

Among the software components that make this interconnection feasible across diverse and similar nodes are: Components and modular units with very specific contents or services. An example is an enterprise resource planning (ERP) implementation, where each core processing area is divided into modules and each with its programs suite and database interconnected between modules. Another example is where the data needed for a particular transaction is shown, preserving the integrity and security of the data managed by the operations and applications. Interfaces are small sсrіpts or code that facilitates communication or presentation to users across the network. Connectors are small sсrіpts designed to establish communications and share information across dissimilar networks and applications. Written in low-level programming languages like C, C++, or Java, connectors include code and protocol to establish communication between dissimilar systems, operating systems, and applications; and once that communication is settled, file sharing and processing are executed or transmitted. Certain styles for software architecture within a distributed system are explored this week. The most used architectural environments in terms of software processing include the following: Layered Architecture: In this arrangement, components or modules are organized in layers, where one module executes a call to another and waits for a response with the expected output or processing message. Calls could be downwards or upwards, but the most common is down call (request-response), or one-way-call. For this software architecture arrangement, the transmission control protocol of the TCP/IP suite intervenes to facilitate the exchange of calls and message parsing across resources. Application layering structures are distributed or structured in three layers, application interface layer, processing level, and data level. Object-Based Architecture: In this style, each object is defined as a component, and each is connected using a procedure called mechanism, permitting encapsulation of data—that is, they can be seen as a single entity. This arrangement makes it possible to run the interface sсrіpt from one node or machine, and the object or data is located in another. Service-Oriented Architecture (SOA): The services are separated from one another so that they can run independently. In a service-oriented architecture, a distributed application is built as a composition of many different services. These services are encapsulated into a single unit becoming a single interface that can be run by the users. (van Steen, & Tanenbaum, 2017). Resource-Based Architecture: In this arrangement, services are compiled and managed as modules or components. These modules or components can be changed, added, or removed from the module or component and identified by using a naming scheme. Messages are described and sent across the nodes using basic commands like PUT, GET, DELETE, POST. Middleware Organization: This arrangement is independent of the overall organization of the distributed system, as it is aligned in a separate processing layer. Two types of patterns in middleware are wrappers (a component of which options are transformed into variables of the component), and interceptor (code that will break the usual flow of execution, and control is transferred to another module for execution). While hardware designs can easily be exploited to work together, it takes special software to actually coordinate distributed problem-solving. Middleware and other software infrastructure components provide the basic communication facilities to overcome the differences in hardware and software that you will find when talking about creating networks of hundreds or thousands of devices. DCE, CORBA, and Jini are a few of the more established software suites used to coordinate heterogeneous systems for distributed problem-solving. Middleware applications have been around for some time, and one of the earlier ones was called DCE. While DCE is old, you can still find it in use today. DCE is based on remote procedure calls (RPC) and provides an array of services, including directory services, security services based on Kerberos, and distributed file services. You will take a closer look at RPC later in the course. But for now, it is enough to know it is used in some of the most popular systems in use today. CORBA is one of the most widely used and well-known distributed systems in use today. CORBA stands for common object request broker architecture and is supported by a consortium of industry professionals. Where it differs from DCE is that is it based on object-oriented concepts. Because CORBA is maintained by a consortium, it remains current and open. However, static distributed systems were the model when CORBA was designed. These systems require considerable resources while running and retain the classic client/server model as its basic design. With the trends in hardware moving toward smaller devices, the desire for more dynamic distributed systems and services has arisen. Instead of fixed systems, we are looking to design spontaneous systems that add and remove clients regularly. Jini is an old model that is getting new life with the Apache foundation as River. The distributed model in Jini is based on Java allowing any device running a JVM to dynamically participate in the system. Services can be assigned to entities on the network to be used by individuals, programs, and/or other services. Jini and similar systems are better suited than CORBA for dynamic distributed systems where components may be mobile and form spontaneous networks, an important trend in distributed systems when you consider trends in hardware. Techopedia defines Jini as a service-oriented architecture that defines a programming model that exploits and extends Java technology. This enables the construction of secure, distributed systems by building scalable and flexible networks. (Techopedia, 2018). Review the weekly resources (and previously provided resources, as needed) to prepare for this week’s assignment. The resources may include textbook reading assignments, journal articles, websites, links to tools or software, videos, handouts, rubrics, etc. References Techopedia. (n.d.) Definition of Jini. Here′s the assignment task list..