Evolution and evolution of Atitit software architecture method CS BS SOA Roa MSA Attilax Summary

Evolution and Evolution of Atitit Software architecture method CS BS SOA Roa MSA attilax Summary

1.1. Software architecture is along the stand-alone to CS and then to bs three-tier architecture and even multi-layered architectures evolve over multiple architectures 1

1.2. main Evolutionary route Cs " bs " SOA"MSA " ( micro-service architecture 1

1.3. 1

1.4. Resource-Oriented architecture (ROA)1

1.4.1. Piping and filter style (data flow style)2

1.5. Data Abstraction and object-oriented style (call / return style)2

1.6. Event-based implicit invocation style (standalone component style)2

1.7. Hierarchical system style (call / return style)3

1.8. Reference 3

2. 4

Software Architecture Knowledge Map N Technology Tree

1.1. The software architecture is evolving along the stand-alone to CS architecture, to the three-tier architecture of BS, and even to multi -layered architectures.

1.2. Main Evolutionary course Cs " bs " " SOAMSA( microservices architecture )1.3.  

Hybrid

1.4. resource-oriented architecture (ROA)

based on REST 's software architecture style (software Architecture style) is called resource-oriented architecture (resource-oriented Architecture,ROA

1.4.1. Pipeline and filter style (data flow style)

in the pipeline /filter style software architecture, each component has a set of inputs and outputs, the component reads the input data stream, is processed internally, and then produces the output data stream. This process is usually done through the transformation of the input stream and the incremental calculation, so the output is generated before the inputs are fully consumed. Thus, the component here is called a filter, and this style of connection is like a conduit for data flow, and the output of one filter is transmitted to the input of another filter. A filter that is particularly important in this style must be a separate entity, it cannot share data with other filters, and a filter does not know its upstream and downstream identities. The correctness of a pipeline/filter network output is not dependent on the order in which the filters perform the incremental calculation process.

The pipeline /filter style software architecture has many good features:

(1) Make the soft component have good concealment and high cohesion, low coupling characteristic;

(2) allows the designer to regard the input/output behavior of the whole system as a simple synthesis of the behavior of multiple filters;

(3) Support software reuse. Important to provide data that is suitable for transmission between the two filters, any two filters can be connected together;

(4) System maintenance and enhance the performance of systems is simple. New filters can be added to existing systems, and old ones can be replaced by improved filters;

(5) Allow the analysis of some properties such as throughput, deadlock, etc.

(6) Support parallel execution. Each filter is completed as a separate task, so it can be executed in parallel with other tasks.

However, such a system also has a number of adverse factors.

(1) Typically causes a process to become a batch structure. This is because while filters can process data incrementally, they are independent, so designers must consider each filter as a complete transformation from input to output.

(2) An application that is not suitable for dealing with interactions. This is especially true when there is a need for incremental display of changes.

(3) because there is no common standard in data transmission, each filter increases the work of parsing and synthesizing data, which leads to degraded system performance and increases the complexity of writing filters.

1.5. Data abstraction and object-oriented style (call / return style)

Abstract data type concept plays an important role in software system, and now the software industry has turned to the use of object-oriented system. This style is based on data abstraction and object-oriented, and the representations of data and their corresponding operations are encapsulated in an abstract data type or object. A component of this style is an instance of an object, or an abstract data type. An object is a component called a manager, because it is responsible for maintaining the integrity of the resource. Objects are interacted with by calls to functions and procedures.

1.6. Event-based implicit invocation style (standalone component style)

The idea of an event-based implicit invocation style is that a component does not invoke a process directly, but instead triggers or broadcasts one or more events. Procedures in other components of the system are registered in one or more events, and when an event is triggered, the system automatically invokes all the processes registered in the event, so that the triggering of one event results in a call to the procedure in another module.

Architecture, this style of components is a number of modules, which can be a number of processes, but also can be a collection of events. Procedures can be called in a generic manner, or they can be registered in system events, which are called when these events occur.

The main feature of an event-based implicit invocation style is that the event's trigger does not know which artifacts are affected by these events. This does not assume the order in which the artifacts are processed, or even what processes are called, so many implicitly called systems also contain explicit calls as complementary forms of component interaction.

There are many application systems that support event-based implicit invocation. For example, it is used in a programming environment to integrate tools, to ensure consistency constraints on data in a database management system, to manage data in a user interface system, and to support grammar checking in the editor. For example, in a system, the editor and variable monitor can register the corresponding debugger breakpoint event. When debugger stops at a breakpoint, it declares the event, and the handler is automatically called by the system, such as an editor that can roll the screen to a breakpoint, and the variable monitor refreshes the variable value. Debugger itself only declares events, does not care about which processes will start, and does not care what the processes do.

The main advantages of an implicit calling system are:

(1) It provides powerful support for software reuse. When a component needs to be added to an existing system, it is only necessary to register it in the event of the system.

(2) To improve the system to bring convenience. When one component is substituted for another, the interface of other components is not affected.

The main drawbacks of implicit calling systems are:

(1) The component abandons the control of the system calculation. When a component triggers an event, it is not determined whether other artifacts will respond to it. And even if it knows what artifacts the event registers, it does not guarantee the order in which the processes are called.

(2) The problem of data exchange. Sometimes data can be passed by one event, but in other cases, an event-based system must rely on a shared warehouse for interaction. In these cases, global performance and resource management becomes a problem.

(3) Since the semantics of the process must depend on the context constraints of the triggered event, there is a problem with the inference of correctness.

1.7. Hierarchical System style (call / return style)

hierarchical systems are organized into a hierarchy, with each layer serving as a top level and as a downlevel customer. In some hierarchical systems, in addition to some carefully selected output functions, the inner layer is visible only to adjacent layers. In such a system, a component implements a virtual machine in some layers (which is partially opaque at the middle level of another hierarchy of systems). A connector is defined by a protocol that determines how layers interact, and topology constraints include constraints on interactions between adjacent layers.

1.8. References

based on Service Oriented architecture ( SOA) andThe business component Model for resource-based architecture (ROA) . html

Classic Software Architecture mode _ erudite Wisdom Deep _ Sina blog . html

author ::   nickname : Old Wow's paw claw of Eagle   Idol-destroying iconoclast Image-smasher

King of Bird Catcher King of Kings devout pious religious defender Defender of /c6> the Faith caracalla red cloak Caracalla red cloak

abbreviation:: Emir attilax Akbar Emile Atiraca

Full Name::Emir attilax Akbar bin Mahmud bin Attila bin Solomon bin Adam Al Rapanui  Emir Attilax Akbar ben Mahmud   ben Attila Solomon Ben Adam   al  Rapa Nui

Common name: Etila (Ayron), email:[email protected]

title:Head of Uke headquarters, founder of Global Grid project,

Uke, Minister of Religious and Cultural Integration Affairs, Vice-Chairman of the Uke Reformation Commission

, Chief chieftain of the Uke tribe,

Uke system and chairman of the major conference committee, Uke Security Department Chief Brigade, Uke System Inspection Committee vice President,

CTO of Cow Technology , director, Research and Development director, Chief CTO Technical Director , uke

uke Polynesia District chain Head Regional head of the Kingdom of Tonga.

uke Kerr Glen Islands chain Head, Line Is. district chain Head,

uke Bouvet and South Georgia and South Sandwich Is. regional chain head

Uke, chairman of the Association of Software Standardization Uke, vice President of lifelong Education School

Uke, vice president of the Association of Database and Storage standardization, editor of Uke Publishing house

Uke Hospital and medical school founder of the field

reprint Please indicate source:Attilax's column? http://www.cnblogs.com/attilax/

--atiend

2.  

Evolution and evolution of Atitit software architecture method CS BS SOA Roa MSA Attilax Summary