Model-oriented software architecture 2-concurrent and networked object models Reading Notes (1)-concurrent and networked objects

1. Concurrent and networked objects

1. Motivation

The mismatch between the rapid development of hardware and the slow development of software has many factors:

1) inherent and occasional complexity. Inherent complexity comes from basic domain difficulties, such as processing partial failures, distributed deadlocks, and end-to-end QoS requirements. Occasional complexity comes from the limitations of software tools and development technologies, such as unportable programming APIs and poor distributed debugger.

2) inappropriate methods and technologies. Popular software analysis methods and design techniques mainly focus on constructing single processes and single-threaded applications. The development of high-quality concurrent and networked systems relies on the intuition and expertise of skilled software architecture designers and engineers.

3) repeatedly develop and rediscover core concepts and technologies.

 

Pattern is a solution to reproduce a standard problem in a special context. pattern helps capture and reuse static and dynamic structures in software design and collaboration between key participants. In particular, the mode can do the following:

1) Use developers to focus on more advanced software application architectures and designs, such as appropriate service access and configuration, event processing, and thread model specifications. These are important strategic aspects of concurrency and networking software.

2) Avoid developers from focusing on low-level operating systems and network protocols and mechanisms.

 

2. Difficulties in concurrent and networked Software

Developers must face issues that are not involved in or are not very problematic with independent applications:

1) establish a connection and initialize the service.

2) Multi-Channel event decomposition and Event ProcessingProgramAllocate.

3) inter-process communication (IPC) and network protocols.

4) Primary and secondary memory management and caching.

5) static and dynamic component configuration.

6) concurrency and synchronization.

 

In the context of these themes, there will be many design and programming difficulties:

1) Common inherent complexities related to concurrent and networked systems include managing bandwidth, minimizing latency and latency deviation (jitter) detect and recover some failures, determine proper service division and load balancing policies, and ensure the causal sequence of events. Similarly, common inherent complexities in concurrent programming include eliminating competition conditions and avoiding deadlocks, determining appropriate Thread Scheduling Policies, and optimizing terminal system protocol processing performance.

2) related to concurrency and network systems, common incidental Complexities include the lack of Portable Operating System APIs, inadequate debugging support, and the lack of tools for analyzing concurrent and networked applications.AlgorithmDecomposition, continuous re-discovery, and repeated invention of core concepts and common components.

 

2.1 service access and Configuration

Components in independent applications can use function calls to PASS Parameters and access global variables to collaborate within a single address space. In a networked application, components can collaborate using the following means:

1) inter-process communication (IPC) mechanisms, such as shared memory, pipelines, and sockets.

2) communication protocols, such as telnet, FTP, SMTP, HTTP, and LDAP.

3) use advanced communication middleware such as COM + and CORBA to perform remote operations on application-level service components.

 

For infrastructure connection or system programs (such as telnet or FTP), traditional service access includes calling the following APIs:

1) Call the concurrent service access API to manage concurrency, such as UNIX processes, POSIX pthreads, or Win32 threads.

2) Call the IPC service to access APIs, such as UNIX and Internet sockets, and configure connections and communications between processes on a single host or different hosts.

However, when you access the network connection and host services through the C language API of the lower-Layer Operating System, there are several occasional complexities:

1) Excessive Low-layer details.

2) incompatible advanced programming abstraction is constantly re-discovered and re-invented.

3) high possibility of errors.

4) Lack of portability.

5) steep learning curves.

6) scale in proportion to deal with increasing complexity.

Therefore, the most important design challenge of infrastructure connection or system programs is to minimize the aforementioned occasional complexity without sacrificing performance.

 

Supports the static and dynamic evolution of services and applications. The evolution can appear in two ways:

1) You can change the interface for the component service role and the interconnection between the component service role at runtime. The new service role can be implemented and installed in the existing component.

2) by reconfiguration the service load to utilize the processing capability of multiple hosts, the distributed system performance can be improved.

Ideally, these component configurations and reconfiguration changes should be transparent to client applications that access the service. However, it is more challenging to determine how to access services configured to the system by "On-Demand". The implementation of this service is unknown when the system was initially designed.

Many modern operating systems and runtime environments provide explicit dynamic link APIs that allow you to configure applications as needed. However, configuring a service to an application as needed requires not only a Dynamic Link Mechanism-it needs to be used for coordinating (re-configuring) the policy mode. The design challenges here are two aspects. First, even if the application may not know their detailed interfaces, it must export new services. Second, the application must transparently export these services even during runtime, robust integration into its own control flow and processing sequence.

In independent and networked software systems and applications, four effective programming APIs are designed to access and configure services and components. They are the wrapper facade), component configurator, interceptor, and extension interface ).

 

2.2 event handling

As systems become increasingly networked, software development technologies that support event-driven applications become increasingly common. The following three features differentiate event-driven applications from those with traditional "self-directed" control flows:

1) application behavior is triggered by external or internal events that occur asynchronously. These events include the device driver, I/O port, sensor, keyboard or mouse, signal, timer, or other asynchronous software components.

2) most events must be processed quickly to prevent the shortage of CPU resources, improve the perceptible response time, and prevent hardware with real-time constraints from failing or damaging data.

3) a finite state machine may be required to control event processing and detect illegal conversions, because event-driven applications usually have little or no control over event arrival order.

 

Therefore, event-driven applications are often constructed into a layered architecture that is commonly referred to as "inversion of control.

1) The underlying layer is the event source, which detects and retrieves events from various hardware devices or low-level software device drivers residing in the operating system.

2) the next layer is the event demultiplexer, which uses functions like select () to wait for the event list on a variety of event sources, then, the events are allocated to their corresponding event handler for callback.

3) event handler and ApplicationCodeTogether, form another layer, which executes the application-related processing of the response callback-so there is the name of "control conversion.

These patterns describe how to effectively initialize, receive, multi-channel decomposition, allocate, and process various types of events in a networked software framework. Includes reactor, proactor, asynchronous completion token, act, and acceptor-connector ).