SlideShare a Scribd company logo
Microkernel Architecture
based on Pipes and Filters
Anton Semenchenko
About myself 
Co-creator of communities
www.COMAQA.BY and
www.CoreHard.by, co-
founder of company
www.DPI.Solutions,
«tricky» manager at EPAM
Systems.
Agenda
1. Idea
2. History
3. Microkernel Architecture
4. Pipes and Filters
5. Microservices Architecture
6. Summary
7. Examples
8. Quality assurance
9. What’s next
10.Books
11.Engineers from 70-s
Idea
1. Everything new - is totally forgotten old things
2. Study, study and study once again
3. Read books
4. Think about the idea, and do not drown in tons of terminology
and positioning slogans
History 
1. Microkernel Architecture conception – 1960-s
2. Pipes and Filters conception – 1960-s
3. UNIX – 1970 (+ Dennis MacAlistair Ritchie)
4. UNIX pipeline – 1973 (Malcolm Douglas McIlroy)
5. Component-based software engineering – 1987 (Niklaus Emil
Wirth)
6. Component-based unification – 1989 (Bertrand Meyer)
7. COM – 1993
8. CORBA – 1990-s
9. SOAP – 1990-s  2000-s
10.JavaBeans
11..Net components
12.Microservices initial definition – 2005
13.Microservices Architecture - 2012
14.PowerShells
Microkernel
Introduction
1. The Microkernel architectural pattern applies to software
systems that must be able to adapt to changing system
requirements.
2. It separates a minimal functional core from extended
functionality and customer specific parts.
3. The microkernel also serves as a socket for plugging in these
extensions and coordinating their collaboration.
4. Microkernel systems have mainly been described in relation to
the design of operating systems. However, this pattern is also
 mainly applicable to other domains, e.g. financial
applications and database systems.
Challange
1. How to design an architecture for the development of several
applications with similar programming interfaces that
build on the same core functionality.
Context
1. Developing software for an application domain that needs
to cope with a broad spectrum of similar standards and
technologies is a nontrivial task.
2. Well-known examples are application platforms such as
operating systems and graphical user interfaces.
3. Such systems often have a long life-span, often ten years
or more.
4. Over time periods of this length, new technologies emerge
and old ones change.
Context
5. Some applications exist in multiple versions. – Each version
offers a different set of functionality to its users, or differs from
other versions in specific aspects, such as its user interface. –
Despite their differences, however, all versions of the
application should be based on a common architecture
and functional core.
6. The goal is to avoid architectural drift between the versions
of the application and to minimize development and
maintenance effort for shared functionality.
7. It should be easy to provide a particular application version
with different user interfaces, and also to run the version on
different platforms.
“Features”
1. The application platform must cope with continuous hardware
and software evolution.
2. The application platform should be portable, extensible and
adaptable to allow easy integration of emerging
technologies.
3. The success of such application platforms may also depend on
their capability to run applications written for existing
standards.
4. To support a broad range of applications, there is a need
for more than one view of the functionality of the underlying
application platform.
5. Ideally, an application platform (such as an operating system
or a database) should also be able to emulate other
application platforms that belong to the same application
domain.
Solution
1. Compose different versions of the application by extending a
common but minimal core via a “plug-and-play” infrastructure.
2. The Microkernel pattern defines five kinds of participating
components:
• Microkernel
• Internal servers
• External servers
• Adapters
• Clients
Solution
3. The microkernel implements the fundamental functionality
shared by all application versions and provides the
infrastructure for integrating version specific
functionality.
4. Internal servers implement version specific core functionality,
and external servers version specific user interfaces or APIs.
5. A specific application version is configured by connecting
the corresponding internal servers with the microkernel,
and providing appropriate external servers to access its
functionality.
6. Consequently, all versions of the application share a
common functional and infrastructural core, but provide a
tailored function set and look-and-feel.
Solution
7. Clients, whether human or other software systems, access
the microkernel’s functionality solely via the interfaces or
APIs provided by the external servers, which forward all
requests they receive to the microkernel.
8. If the microkernel implements the requested function itself, it
executes the function, otherwise it routes the request to the
corresponding internal server.
9. Results are returned accordingly so that the external servers
can display or deliver them to the client.
Solution
10. A problem arises if a client needs to access the interfaces of
its external server directly.
• – Every communication with an external server must be
hardcoded into the client code.
• – Such a tight coupling between clients and servers does not
support changeability very well.
10. We therefore introduce interfaces between clients and their
external servers to protect clients from direct
dependencies.
11. Adapters represent these interfaces between clients and
their external servers, and allow clients to access the
services of their external server in a portable way..
Tech details
1. The internal structure of the microkernel is typically based on
Layers.
• – The bottommost layer abstracts from the underlying
system platform, thereby supporting the portability of all
higher levels.
• – The second layer implements infrastructure functionality,
such as resource management, on which the microkernel
depends.
• – The layer above hosts the domain functionality that is
shared by all application versions.
• – The topmost layer includes the mechanisms for
configuring internal servers with the microkernel, as well
as for routing requests from external servers to their intended
recipient.
Tech details
2. The microkernel should be kept as small a s possible to
reduce memory requirements and provide mechanisms that
execute quickly.
• – Additional and more complex services are therefore
implemented by internal servers that the microkernel
activates or loads only when necessary.
Internal and External Server
1. Internal servers can be considered extensions of the
microkernel and are only accessible by the microkernel
component.
2. Internal servers may be implemented as separate processes
or as shared libraries:
• – Graphics card drivers are developed as shared libraries
because they only act on behalf of clients.
• – In contrast, page fault handlers are separate processes.
They always have to remain in main memory and cannot be
swapped to external storage.
3. Internal servers follow a similar Layers design as the
microkernel, but do not usually provide a routing layer.
4. Each external server is implemented as a separate process
that provides its own service interface. The internal
architecture of an external server depends on the policies it
comprises.
Benefits
1. Portability. A Microkernel system offers a high degree of
portability, for two reasons:
• – In most cases you do not need to port external servers or
client applications if you port the Microkernel system to a new
software or hardware environment.
• – Migrating the microkernel to a new hardware environment
only requires modifications to the hardware-dependent parts
of the microkernel and does not affect external servers.
2. Flexibility and Extensibility.
• – If you need to implement an additional view, all you need to
do is add a new external server.
• – Extending the system with additional capabilities only
requires the addition or extension of internal servers
Benefits
3. Separation of policy and mechanism.
• – The microkernel component provides all the
mechanisms necessary to enable external servers to
implement their policies.
• – This strict separation of policies and mechanisms
increases the maintainability and changeability of the
whole system
• – It also allows you to add new external servers that
implement their own specialized views. If the microkernel
component were to implement policies, this would
unnecessarily limit the views that could be implemented by
external servers.
Benefits
4. Scalability.
• – A distributed Microkernel system is applicable to the
development of operating systems or database systems for
computer networks, or multiprocessors with local memory.
• – If your Microkernel system works on a network of
machines, it is easy to scale the Microkernel system to the
new configuration when you add a new machine to the
network.
3. Transparency.
• – In a distributed system components can be distributed over
a network of machines.
• – In such a configuration, the Microkernel architecture allows
each component to access other components without
needing to know their location. All details of inter-process
communication with servers are hidden from clients by the
adapters and the microkernel.
Limitations  drawbacks
1. Performance.
• – A monolithic software system designed to offer a specific
view will generally have better performance than a
Microkernel system supporting different views.
• – We therefore have to pay a price for flexibility and
extensibility.
• – If the communication within the Microkernel system is
optimized for performance, however, this price can be
small
Limitations  drawbacks
2. Complexity of design and implementation.
• – Developing a Microkernel-based system is a non-trivial
task.
• – For example, it can sometimes be very difficult to analyze
or predict the basic mechanisms a microkernel
component must provide.
• – In addition, the separation between mechanisms and
policies requires in-depth domain knowledge and
considerable effort during requirements analysis and
design
Pipes and Filters
Introduction
1. The Pipes and Filters architectural pattern provides a
structure for systems that process a stream of data.
2. Each processing step is encapsulated in a filter
component.
3. Data is passed through pipes between adjacent filters.
4. Recombining filters allows you to build families of related
systems.
Example
1. Suppose we want to develop a new compiler for the Java 
programming language.
2. We want the compiler to produce either optimized byte-code to
run on a JVM, or optimized machine code to run natively on
various platforms
• – Similar to the GNU GCJ compiler.
3. A backend will translate byte-code into the machine
instructions of a specific processor for best performance.
4. Conceptually, translation from Java to byte-code consists of
the phases lexical analysis, syntax analysis, semantic
analysis, byte-code generation, byte-code optimization, and
optionally machine-code generation.
5. Each stage has well-defined input and output data.
Example
Challange
1. How to provide a design that is suitable for processing data
streams.
Context
1. Some applications process streams of data.
• – Input data streams are transformed stepwise into output data
streams.
2. However, using common and familiar request/ response
semantics for structuring such types of application is typically
impractical.
3. Instead we must specify an appropriate data flow model for
them.
Context
4. Modeling a data-flow-driven application raises some non-
trivial developmental and operational challenges.
5. First, the parts of the application should correspond to
discrete and distinguishable actions on the data flow.
6. Second, some usage scenarios require explicit access to
intermediate yet meaningful results.
7. Third, the chosen data flow model should allow applications
to read, process, and write data streams incrementally rather
than wholesale and sequentially so that throughput is
maximized.
8. Lastly, long-duration processing activities must not become a
performance bottleneck.
“Features”
1. Future system enhancements should be possible by
exchanging processing steps or by recombination of steps,
even by users.
2. Small processing steps are easier to reuse in different contexts
than large components.
3. Non-adjacent processing steps do not share information.
4. Different sources of input data exist, such as a network
connection or a hardware sensor providing temperature
readings, for example.
5. It should be possible to present or store final results in various
ways.
6. Explicit storage of intermediate results for further processing in
files clutters directories and is error-prone, if done by users.
7. You may not want to rule out multi-processing the steps, for
example running them in parallel or quasi-parallel.
Solution
1. The Pipes and Filters architectural pattern divides the task of a
system into several sequential processing steps.
2. These steps are connected by the data flow through the
system. The output data of a step is the input to the
subsequent step.
3. Each processing step is implemented by a filter component.
4. A filter consumes and delivers data incrementally, in contrast
to consuming all its input before producing any output, to
achieve low latency and enable real parallel processing
Solution
5. The input to the system is provided by a data source such as
a text file. The output flows into a data sink such as a file,
terminal, animation program and so on.
6. The data source, the filters and the data sink are connected
sequentially by pipes that buffer data.
7. Each pipe implements the data flow between adjacent
processing steps.
8. The sequence of filters combined by pipes is called a
processing pipeline
Solution
Solution
9. In a single-process arrangement, pipes are typically
implemented as queues.
10. In a distributed arrangement, pipes are realized as some form
of messaging infrastructure that passes data streams
between remote filters.
11. If a filter performs a long-duration activity, consider integrating
multiple parallel instances of the filter into the processing
chain.
• Such a configuration can further increase system
performance and throughput, as some filter instances can
start processing new data streams while others are
processing previous data streams.
Filter Tech details
1. Filter components are the processing units of the pipeline.
2. A filter enriches data by computing and adding information,
refines data by concentrating or extracting information, and
transforms data by delivering the data in some other
representation. A concrete filter implementation may combine
any of these three basic principles.
3. An active filter starts processing on its own as a separate
program or thread. Most commonly, the filter is active in a
loop, pulling its input from and pushing its output down the
pipeline.
4. A passive filter component is activated by being called either
as a function (pull) or as a procedure (push).
Pipe Tech details
1. Pipes denote the connections between filters, between the
data source and the first filter, and between the last filter and
the data sink.
2. If two active components are joined, the pipe synchronizes
them. This synchronization is done with a first-in-first-out
buffer (queue).
3. If activity is controlled by one of the adjacent filters, the pipe
can be implemented by a direct call from one filter to the next.
Direct calls make filter recombination harder, however.
Options
1. The single-input single-output filter specification of the Pipes
and Filters pattern can be varied to allow filters with more
than one input and/or more than one output.
2. Processing can then be set up a s a directed graph that can
even contain feedback loops.
• – The design of such a system, especially one with feedback
loops, requires a solid foundation to explain and understand
the complete calculation.
• – A rigorous theoretical analysis and specification using
formal methods are appropriate, to prove that the system
terminates and produces the desired result.
3. If we restrict ourselves to simple directed acyclic graphs,
however, it is still possible to build useful systems.
Benefits
1. A Pipes and Filters architecture decouples different data
processing steps so that they can evolve independently of
one another and support an incremental data processing
approach.
2. Pipes and Filters provides for flexibility by exchanging or
reordering the processing steps.
3. Recombining filters allows you to build families of related
systems using existing processing components.
Benefits
4. Applicability
• Whether a separation into processing steps is feasible
strongly depends on the application domain and the problem
to be solved. For example, an interactive, event-driven
system does not split into sequential stages.
Microservices Architecture
Context
Just a popular context
1. Server-side enterprise application.
2. A variety of different clients support
• Desktop browsers
• Mobile browsers
• Native mobile applications
3. Expose an API for 3rd parties to consume
4. Integrate with other applications via either web services or a
message broker
5. Handles requests (HTTP requests and messages) by
executing business logic; accessing a database; exchanging
messages with other systems; and returning a
HTML/JSON/XML response.
6. There are logical components corresponding to different
functional areas of the application.
“Features”
1. There is a team of developers working on the application
2. New team members must quickly become productive
3. The application must be easy to understand and modify
4. You want to practice continuous deployment of the
application
5. You must run multiple copies of the application on multiple
machines in order to satisfy scalability and availability
requirements
6. You want to take advantage of emerging technologies
(frameworks, programming languages, etc)
The Scale Cube
Solution
1. Define an architecture that structures the application as a set
of loosely coupled, collaborating services. This approach
corresponds to the Y-axis of the Scale Cube. Each
service implements a set of narrowly, related functions.
For example, an application might consist of services such as
the order management service, the customer management
service etc.
2. Services communicate using either synchronous protocols
such as HTTP/REST or asynchronous protocols such as
AMQP. Services can be developed and deployed
independently of one another. Each service has its own
database in order to be decoupled from other services.
Data consistency between services is maintained using
an event-driven architecture
The Scale Cube
Microservices Architecture
Summary
1. Everything new - is totally forgotten old things
2. Study, study and study once again
3. Read books
4. Think about the idea, and do not drown in tons of terminology
and positioning slogans
5. Microkernel, Pipes and Filters, Microservicies – great
Architectural options
Examples
UNIX philosophy by Malcolm
1. Make each program do one thing well. To do a new job, build
afresh rather than complicate old programs by adding new
"features".
2. Expect the output of every program to become the input to
another, as yet unknown, program. Don't clutter output with
extraneous information. Avoid stringently columnar or binary
input formats. Don't insist on interactive input.
3. Design and build software, even operating systems, to be
tried early, ideally within weeks. Don't hesitate to throw
away the clumsy parts and rebuild them.
4. Use tools in preference to unskilled help to lighten a
programming task, even if you have to detour to build the
tools and expect to throw some of them out after you've
finished using them.
DSL based solutions
1. Health insurance for USA and Canada
2. The world leader of Hardware production
• Trains and wagons “management”
• Calculation, optimization, rule based option selection for
electrical networks
• Note: super- general cores and DSL configurations
3. Paper’s advertisement for USA
DSL based - video
1. Analyst Days 2015. Антон Наумович. Роль бизнес-
аналитика в разработке собственной Business Rule
Engine с нуля как основной платформы проекта
2. Юрий Русович. Особенности системного анализа особо
крупных проектов построенных на базе Business Rule
Engine «Drools»
3. Александр Василенок. XText – Business Rule Engine в
контексте бизнес-анализа
4. Антон Семенченко. BDD or DSL как способ построения
коммуникации на проекте
5. Антон Наумович. Разработка своей agile методологии для
управления крупными проектами
Let’s vote ??? 
1. Microkernel?
2. Microservices?
3. Pipes and Filters ..?
Example
EPAM Report Portal
• Transition from Monolithic solution to Microservicies
architecture
Architecture – Methodology
1. Антон Наумович. Разработка своей agile методологии для
управления крупными проектами
2. When it’s worth moving from Agile to Waterfall
Quality assurance
Examples
1. Unix philosophy
2. Health insurance for USA and Canada
3. The world leader of Hardware production
• Trains and wagons “management”
• Calculation, optimization, rule based option selection for
electrical networks
3. Paper’s advertisement for USA
4. EPAM Report Portal
What’s next
Books
Examples
• «Pattern-Oriented Software Architecture» Volume 1-3
Notes: I highly recommend to read it from start to the very end.
• «Domain Specific Languages» Martin Fowler
Notes: I highly recommend to read it from start to the very end.
• «Patterns of Enterprise Application Architecture» Martin
Fowler
Notes: I highly recommend to read it from start to the very end.
• «The Pragmatic Programmer: From Journeyman to
Master» D.Thomas, A. Hunt
Notes: A great book, consisting a whole diversity of atomic
advise. IMHO required to be read from the beginning to the end
twice and then look through various chapters when preparing to
the interview or discussion with the customer.
Engineers from 70-s
Dennis MacAlistair Ritchie
1. C
2. Unix
3. Dozens of brilliant inventions
Malcolm Douglas McIlroy
1. Unix pipelines
2. Software componentry
3. Dozens of Unix utilities
Niklaus Emil Wirth
1. Pascal
2. Component-based software engineering
3. Dozens of brilliant inventions
Bertrand Meyer
1. Component-based unification
2. Dozens of brilliant inventions
3. Innopolis University lecturer (Russia)
Thanks! Questions?
Anton Semenchenko
skype: dpi.semenchenko
semenchenko@dpi.solutions

More Related Content

What's hot

4 deus leaflet wp4
4 deus leaflet wp44 deus leaflet wp4
4 deus leaflet wp4
imec.archive
 
middleware
middlewaremiddleware
middleware
rajeswarimca
 
Distributed network
Distributed networkDistributed network
Distributed network
Dhani Ahmad
 
middleware
middlewaremiddleware
middleware
rkk0o7
 
network design and administration
network design and administrationnetwork design and administration
network design and administration
erick chuwa
 
Fault tolerance in Information Centric Networks
Fault tolerance in Information Centric NetworksFault tolerance in Information Centric Networks
Fault tolerance in Information Centric Networks
Nitinder Mohan
 
Webtech presentation
Webtech presentationWebtech presentation
Webtech presentation
Anil Pokhrel
 
Distributed computing environment
Distributed computing environmentDistributed computing environment
Distributed computing environment
Ravi Bhushan
 
IoT Heap 2
IoT Heap 2IoT Heap 2
IoT Heap 2
SushrutaMishra1
 
Distributed operating system
Distributed operating systemDistributed operating system
Distributed operating system
udaya khanal
 
Introduction to distributed system
Introduction to distributed systemIntroduction to distributed system
Introduction to distributed system
ishapadhy
 
Microprocessor presentation
Microprocessor presentationMicroprocessor presentation
Microprocessor presentation
TanmayShete4
 
Project report
Project reportProject report
Project report
ayush13bbm
 
DATA IN CLOUD
DATA IN CLOUDDATA IN CLOUD
DATA IN CLOUD
Rashmi Agale
 
Network Presentation
Network PresentationNetwork Presentation
Network Presentation
AkashSingh621666
 
IRJET-Virtualization Technique for Effective Resource Utilization and Dedicat...
IRJET-Virtualization Technique for Effective Resource Utilization and Dedicat...IRJET-Virtualization Technique for Effective Resource Utilization and Dedicat...
IRJET-Virtualization Technique for Effective Resource Utilization and Dedicat...
IRJET Journal
 
SDN Control Plane scalability research proposal
SDN Control Plane scalability research proposalSDN Control Plane scalability research proposal
SDN Control Plane scalability research proposal
Yatindra shashi
 

What's hot (17)

4 deus leaflet wp4
4 deus leaflet wp44 deus leaflet wp4
4 deus leaflet wp4
 
middleware
middlewaremiddleware
middleware
 
Distributed network
Distributed networkDistributed network
Distributed network
 
middleware
middlewaremiddleware
middleware
 
network design and administration
network design and administrationnetwork design and administration
network design and administration
 
Fault tolerance in Information Centric Networks
Fault tolerance in Information Centric NetworksFault tolerance in Information Centric Networks
Fault tolerance in Information Centric Networks
 
Webtech presentation
Webtech presentationWebtech presentation
Webtech presentation
 
Distributed computing environment
Distributed computing environmentDistributed computing environment
Distributed computing environment
 
IoT Heap 2
IoT Heap 2IoT Heap 2
IoT Heap 2
 
Distributed operating system
Distributed operating systemDistributed operating system
Distributed operating system
 
Introduction to distributed system
Introduction to distributed systemIntroduction to distributed system
Introduction to distributed system
 
Microprocessor presentation
Microprocessor presentationMicroprocessor presentation
Microprocessor presentation
 
Project report
Project reportProject report
Project report
 
DATA IN CLOUD
DATA IN CLOUDDATA IN CLOUD
DATA IN CLOUD
 
Network Presentation
Network PresentationNetwork Presentation
Network Presentation
 
IRJET-Virtualization Technique for Effective Resource Utilization and Dedicat...
IRJET-Virtualization Technique for Effective Resource Utilization and Dedicat...IRJET-Virtualization Technique for Effective Resource Utilization and Dedicat...
IRJET-Virtualization Technique for Effective Resource Utilization and Dedicat...
 
SDN Control Plane scalability research proposal
SDN Control Plane scalability research proposalSDN Control Plane scalability research proposal
SDN Control Plane scalability research proposal
 

Viewers also liked

шишки, набитые за 15 лет использования акторов в c++ v.001.3
шишки, набитые за 15 лет использования акторов в c++ v.001.3шишки, набитые за 15 лет использования акторов в c++ v.001.3
шишки, набитые за 15 лет использования акторов в c++ v.001.3
corehard_by
 
Диаграммы состояний и c++
Диаграммы состояний и c++Диаграммы состояний и c++
Диаграммы состояний и c++
corehard_by
 
Современный статический анализ кода: что умеет он, чего не умели линтеры
Современный статический анализ кода: что умеет он, чего не умели линтерыСовременный статический анализ кода: что умеет он, чего не умели линтеры
Современный статический анализ кода: что умеет он, чего не умели линтеры
corehard_by
 
C++ references
C++ referencesC++ references
C++ references
corehard_by
 
C++ refelection and cats
C++ refelection and catsC++ refelection and cats
C++ refelection and cats
corehard_by
 
модели акторов в с++ миф или реальность
модели акторов в с++ миф или реальностьмодели акторов в с++ миф или реальность
модели акторов в с++ миф или реальность
corehard_by
 
Mixing c++ and python
Mixing c++ and pythonMixing c++ and python
Mixing c++ and python
corehard_by
 
Повседневный С++: алгоритмы и итераторы
Повседневный С++: алгоритмы и итераторы Повседневный С++: алгоритмы и итераторы
Повседневный С++: алгоритмы и итераторы
corehard_by
 
Smp and asmp architecture.
Smp and asmp architecture.Smp and asmp architecture.
Smp and asmp architecture.
Gaurav Dalvi
 
operating system structure
operating system structureoperating system structure
operating system structure
Waseem Ud Din Farooqui
 
Oxygine 2 d objects,events,debug and resources
Oxygine 2 d objects,events,debug and resourcesOxygine 2 d objects,events,debug and resources
Oxygine 2 d objects,events,debug and resources
corehard_by
 
Unit tests final
Unit tests finalUnit tests final
Unit tests final
corehard_by
 
Mixing d ps building architecture on the cross cutting example
Mixing d ps building architecture on the cross cutting exampleMixing d ps building architecture on the cross cutting example
Mixing d ps building architecture on the cross cutting example
corehard_by
 
модель акторов и C++ что, зачем и как ?
модель акторов и C++ что, зачем и как ?модель акторов и C++ что, зачем и как ?
модель акторов и C++ что, зачем и как ?
corehard_by
 
Symmetric multiprocessing (smp)
Symmetric multiprocessing (smp)Symmetric multiprocessing (smp)
Symmetric multiprocessing (smp)
rayhan basher
 
Microkernel
MicrokernelMicrokernel
Microkernel
Suraj Mehta
 
Operating System Overview
Operating System OverviewOperating System Overview
Operating System Overview
Anas Ebrahim
 
Symmetric multiprocessing
Symmetric multiprocessingSymmetric multiprocessing
Symmetric multiprocessing
Mohammad Ali Khan
 
Павел Беликов, Как избежать ошибок, используя современный C++
Павел Беликов, Как избежать ошибок, используя современный C++Павел Беликов, Как избежать ошибок, используя современный C++
Павел Беликов, Как избежать ошибок, используя современный C++
Sergey Platonov
 
Microkernel
MicrokernelMicrokernel
Microkernel
tushart324
 

Viewers also liked (20)

шишки, набитые за 15 лет использования акторов в c++ v.001.3
шишки, набитые за 15 лет использования акторов в c++ v.001.3шишки, набитые за 15 лет использования акторов в c++ v.001.3
шишки, набитые за 15 лет использования акторов в c++ v.001.3
 
Диаграммы состояний и c++
Диаграммы состояний и c++Диаграммы состояний и c++
Диаграммы состояний и c++
 
Современный статический анализ кода: что умеет он, чего не умели линтеры
Современный статический анализ кода: что умеет он, чего не умели линтерыСовременный статический анализ кода: что умеет он, чего не умели линтеры
Современный статический анализ кода: что умеет он, чего не умели линтеры
 
C++ references
C++ referencesC++ references
C++ references
 
C++ refelection and cats
C++ refelection and catsC++ refelection and cats
C++ refelection and cats
 
модели акторов в с++ миф или реальность
модели акторов в с++ миф или реальностьмодели акторов в с++ миф или реальность
модели акторов в с++ миф или реальность
 
Mixing c++ and python
Mixing c++ and pythonMixing c++ and python
Mixing c++ and python
 
Повседневный С++: алгоритмы и итераторы
Повседневный С++: алгоритмы и итераторы Повседневный С++: алгоритмы и итераторы
Повседневный С++: алгоритмы и итераторы
 
Smp and asmp architecture.
Smp and asmp architecture.Smp and asmp architecture.
Smp and asmp architecture.
 
operating system structure
operating system structureoperating system structure
operating system structure
 
Oxygine 2 d objects,events,debug and resources
Oxygine 2 d objects,events,debug and resourcesOxygine 2 d objects,events,debug and resources
Oxygine 2 d objects,events,debug and resources
 
Unit tests final
Unit tests finalUnit tests final
Unit tests final
 
Mixing d ps building architecture on the cross cutting example
Mixing d ps building architecture on the cross cutting exampleMixing d ps building architecture on the cross cutting example
Mixing d ps building architecture on the cross cutting example
 
модель акторов и C++ что, зачем и как ?
модель акторов и C++ что, зачем и как ?модель акторов и C++ что, зачем и как ?
модель акторов и C++ что, зачем и как ?
 
Symmetric multiprocessing (smp)
Symmetric multiprocessing (smp)Symmetric multiprocessing (smp)
Symmetric multiprocessing (smp)
 
Microkernel
MicrokernelMicrokernel
Microkernel
 
Operating System Overview
Operating System OverviewOperating System Overview
Operating System Overview
 
Symmetric multiprocessing
Symmetric multiprocessingSymmetric multiprocessing
Symmetric multiprocessing
 
Павел Беликов, Как избежать ошибок, используя современный C++
Павел Беликов, Как избежать ошибок, используя современный C++Павел Беликов, Как избежать ошибок, используя современный C++
Павел Беликов, Как избежать ошибок, используя современный C++
 
Microkernel
MicrokernelMicrokernel
Microkernel
 

Similar to строим Microkernel architecture на базе паттерна pipes and filters

4. system models
4. system models4. system models
4. system models
AbDul ThaYyal
 
Distributed Operating System
Distributed Operating SystemDistributed Operating System
Distributed Operating System
AjithaG9
 
Comparison of Current Service Mesh Architectures
Comparison of Current Service Mesh ArchitecturesComparison of Current Service Mesh Architectures
Comparison of Current Service Mesh Architectures
Mirantis
 
Unicorn Platform; Basic Usage Guide
Unicorn Platform; Basic Usage GuideUnicorn Platform; Basic Usage Guide
Unicorn Platform; Basic Usage Guide
ubigiannis
 
DEVNET-1142 Decomposing Monolithic Applications to Microservices
DEVNET-1142	Decomposing Monolithic Applications to MicroservicesDEVNET-1142	Decomposing Monolithic Applications to Microservices
DEVNET-1142 Decomposing Monolithic Applications to Microservices
Cisco DevNet
 
The Overview of Microservices Architecture
The Overview of Microservices ArchitectureThe Overview of Microservices Architecture
The Overview of Microservices Architecture
Paria Heidari
 
Microservice Architecture Patterns, by Richard Langlois P. Eng.
Microservice Architecture Patterns, by Richard Langlois P. Eng.Microservice Architecture Patterns, by Richard Langlois P. Eng.
Microservice Architecture Patterns, by Richard Langlois P. Eng.
Richard Langlois P. Eng.
 
Istio as an Enabler for Migrating Monolithic Applications to Microservices v1.3
Istio as an Enabler for Migrating Monolithic Applications to Microservices v1.3Istio as an Enabler for Migrating Monolithic Applications to Microservices v1.3
Istio as an Enabler for Migrating Monolithic Applications to Microservices v1.3
Ahmed Misbah
 
Chat application through client server management system project.pdf
Chat application through client server management system project.pdfChat application through client server management system project.pdf
Chat application through client server management system project.pdf
Kamal Acharya
 
Distributed system
Distributed systemDistributed system
Distributed system
chirag patil
 
Unit ii
Unit ii  Unit ii
Deployability
DeployabilityDeployability
Deployability
Len Bass
 
OOP - Basing Software Development on Reusable
OOP - Basing Software Development on Reusable OOP - Basing Software Development on Reusable
OOP - Basing Software Development on Reusable
17090AshikurRahman
 
Srs
SrsSrs
MicroserviceArchitecture in detail over Monolith.
MicroserviceArchitecture in detail over Monolith.MicroserviceArchitecture in detail over Monolith.
MicroserviceArchitecture in detail over Monolith.
PLovababu
 
MICROSERVICES ARCHITECTURE unit -2.pptx
MICROSERVICES ARCHITECTURE unit -2.pptxMICROSERVICES ARCHITECTURE unit -2.pptx
MICROSERVICES ARCHITECTURE unit -2.pptx
MohammedShahid562503
 
Technology insights: Decision Science Platform
Technology insights: Decision Science PlatformTechnology insights: Decision Science Platform
Technology insights: Decision Science Platform
Decision Science Community
 
CSIR 5G Research
CSIR 5G ResearchCSIR 5G Research
CSIR 5G Research
Sabelo Dlamini
 
TransitioningToMicroServonDocker_MS
TransitioningToMicroServonDocker_MSTransitioningToMicroServonDocker_MS
TransitioningToMicroServonDocker_MS
Lana Kalashnyk
 
Benefits of Containers, Microservices and Containerized Microservices
Benefits of Containers, Microservices and Containerized MicroservicesBenefits of Containers, Microservices and Containerized Microservices
Benefits of Containers, Microservices and Containerized Microservices
HTS Hosting
 

Similar to строим Microkernel architecture на базе паттерна pipes and filters (20)

4. system models
4. system models4. system models
4. system models
 
Distributed Operating System
Distributed Operating SystemDistributed Operating System
Distributed Operating System
 
Comparison of Current Service Mesh Architectures
Comparison of Current Service Mesh ArchitecturesComparison of Current Service Mesh Architectures
Comparison of Current Service Mesh Architectures
 
Unicorn Platform; Basic Usage Guide
Unicorn Platform; Basic Usage GuideUnicorn Platform; Basic Usage Guide
Unicorn Platform; Basic Usage Guide
 
DEVNET-1142 Decomposing Monolithic Applications to Microservices
DEVNET-1142	Decomposing Monolithic Applications to MicroservicesDEVNET-1142	Decomposing Monolithic Applications to Microservices
DEVNET-1142 Decomposing Monolithic Applications to Microservices
 
The Overview of Microservices Architecture
The Overview of Microservices ArchitectureThe Overview of Microservices Architecture
The Overview of Microservices Architecture
 
Microservice Architecture Patterns, by Richard Langlois P. Eng.
Microservice Architecture Patterns, by Richard Langlois P. Eng.Microservice Architecture Patterns, by Richard Langlois P. Eng.
Microservice Architecture Patterns, by Richard Langlois P. Eng.
 
Istio as an Enabler for Migrating Monolithic Applications to Microservices v1.3
Istio as an Enabler for Migrating Monolithic Applications to Microservices v1.3Istio as an Enabler for Migrating Monolithic Applications to Microservices v1.3
Istio as an Enabler for Migrating Monolithic Applications to Microservices v1.3
 
Chat application through client server management system project.pdf
Chat application through client server management system project.pdfChat application through client server management system project.pdf
Chat application through client server management system project.pdf
 
Distributed system
Distributed systemDistributed system
Distributed system
 
Unit ii
Unit ii  Unit ii
Unit ii
 
Deployability
DeployabilityDeployability
Deployability
 
OOP - Basing Software Development on Reusable
OOP - Basing Software Development on Reusable OOP - Basing Software Development on Reusable
OOP - Basing Software Development on Reusable
 
Srs
SrsSrs
Srs
 
MicroserviceArchitecture in detail over Monolith.
MicroserviceArchitecture in detail over Monolith.MicroserviceArchitecture in detail over Monolith.
MicroserviceArchitecture in detail over Monolith.
 
MICROSERVICES ARCHITECTURE unit -2.pptx
MICROSERVICES ARCHITECTURE unit -2.pptxMICROSERVICES ARCHITECTURE unit -2.pptx
MICROSERVICES ARCHITECTURE unit -2.pptx
 
Technology insights: Decision Science Platform
Technology insights: Decision Science PlatformTechnology insights: Decision Science Platform
Technology insights: Decision Science Platform
 
CSIR 5G Research
CSIR 5G ResearchCSIR 5G Research
CSIR 5G Research
 
TransitioningToMicroServonDocker_MS
TransitioningToMicroServonDocker_MSTransitioningToMicroServonDocker_MS
TransitioningToMicroServonDocker_MS
 
Benefits of Containers, Microservices and Containerized Microservices
Benefits of Containers, Microservices and Containerized MicroservicesBenefits of Containers, Microservices and Containerized Microservices
Benefits of Containers, Microservices and Containerized Microservices
 

More from corehard_by

C++ CoreHard Autumn 2018. Создание пакетов для открытых библиотек через conan...
C++ CoreHard Autumn 2018. Создание пакетов для открытых библиотек через conan...C++ CoreHard Autumn 2018. Создание пакетов для открытых библиотек через conan...
C++ CoreHard Autumn 2018. Создание пакетов для открытых библиотек через conan...
corehard_by
 
C++ CoreHard Autumn 2018. Что должен знать каждый C++ программист или Как про...
C++ CoreHard Autumn 2018. Что должен знать каждый C++ программист или Как про...C++ CoreHard Autumn 2018. Что должен знать каждый C++ программист или Как про...
C++ CoreHard Autumn 2018. Что должен знать каждый C++ программист или Как про...
corehard_by
 
C++ CoreHard Autumn 2018. Actors vs CSP vs Tasks vs ... - Евгений Охотников
C++ CoreHard Autumn 2018. Actors vs CSP vs Tasks vs ... - Евгений ОхотниковC++ CoreHard Autumn 2018. Actors vs CSP vs Tasks vs ... - Евгений Охотников
C++ CoreHard Autumn 2018. Actors vs CSP vs Tasks vs ... - Евгений Охотников
corehard_by
 
C++ CoreHard Autumn 2018. Знай свое "железо": иерархия памяти - Александр Титов
C++ CoreHard Autumn 2018. Знай свое "железо": иерархия памяти - Александр ТитовC++ CoreHard Autumn 2018. Знай свое "железо": иерархия памяти - Александр Титов
C++ CoreHard Autumn 2018. Знай свое "железо": иерархия памяти - Александр Титов
corehard_by
 
C++ CoreHard Autumn 2018. Информационная безопасность и разработка ПО - Евген...
C++ CoreHard Autumn 2018. Информационная безопасность и разработка ПО - Евген...C++ CoreHard Autumn 2018. Информационная безопасность и разработка ПО - Евген...
C++ CoreHard Autumn 2018. Информационная безопасность и разработка ПО - Евген...
corehard_by
 
C++ CoreHard Autumn 2018. Заглядываем под капот «Поясов по C++» - Илья Шишков
C++ CoreHard Autumn 2018. Заглядываем под капот «Поясов по C++» - Илья ШишковC++ CoreHard Autumn 2018. Заглядываем под капот «Поясов по C++» - Илья Шишков
C++ CoreHard Autumn 2018. Заглядываем под капот «Поясов по C++» - Илья Шишков
corehard_by
 
C++ CoreHard Autumn 2018. Ускорение сборки C++ проектов, способы и последстви...
C++ CoreHard Autumn 2018. Ускорение сборки C++ проектов, способы и последстви...C++ CoreHard Autumn 2018. Ускорение сборки C++ проектов, способы и последстви...
C++ CoreHard Autumn 2018. Ускорение сборки C++ проектов, способы и последстви...
corehard_by
 
C++ CoreHard Autumn 2018. Метаклассы: воплощаем мечты в реальность - Сергей С...
C++ CoreHard Autumn 2018. Метаклассы: воплощаем мечты в реальность - Сергей С...C++ CoreHard Autumn 2018. Метаклассы: воплощаем мечты в реальность - Сергей С...
C++ CoreHard Autumn 2018. Метаклассы: воплощаем мечты в реальность - Сергей С...
corehard_by
 
C++ CoreHard Autumn 2018. Что не умеет оптимизировать компилятор - Александр ...
C++ CoreHard Autumn 2018. Что не умеет оптимизировать компилятор - Александр ...C++ CoreHard Autumn 2018. Что не умеет оптимизировать компилятор - Александр ...
C++ CoreHard Autumn 2018. Что не умеет оптимизировать компилятор - Александр ...
corehard_by
 
C++ CoreHard Autumn 2018. Кодогенерация C++ кроссплатформенно. Продолжение - ...
C++ CoreHard Autumn 2018. Кодогенерация C++ кроссплатформенно. Продолжение - ...C++ CoreHard Autumn 2018. Кодогенерация C++ кроссплатформенно. Продолжение - ...
C++ CoreHard Autumn 2018. Кодогенерация C++ кроссплатформенно. Продолжение - ...
corehard_by
 
C++ CoreHard Autumn 2018. Concurrency and Parallelism in C++17 and C++20/23 -...
C++ CoreHard Autumn 2018. Concurrency and Parallelism in C++17 and C++20/23 -...C++ CoreHard Autumn 2018. Concurrency and Parallelism in C++17 and C++20/23 -...
C++ CoreHard Autumn 2018. Concurrency and Parallelism in C++17 and C++20/23 -...
corehard_by
 
C++ CoreHard Autumn 2018. Обработка списков на C++ в функциональном стиле - В...
C++ CoreHard Autumn 2018. Обработка списков на C++ в функциональном стиле - В...C++ CoreHard Autumn 2018. Обработка списков на C++ в функциональном стиле - В...
C++ CoreHard Autumn 2018. Обработка списков на C++ в функциональном стиле - В...
corehard_by
 
C++ Corehard Autumn 2018. Обучаем на Python, применяем на C++ - Павел Филонов
C++ Corehard Autumn 2018. Обучаем на Python, применяем на C++ - Павел ФилоновC++ Corehard Autumn 2018. Обучаем на Python, применяем на C++ - Павел Филонов
C++ Corehard Autumn 2018. Обучаем на Python, применяем на C++ - Павел Филонов
corehard_by
 
C++ CoreHard Autumn 2018. Asynchronous programming with ranges - Ivan Čukić
C++ CoreHard Autumn 2018. Asynchronous programming with ranges - Ivan ČukićC++ CoreHard Autumn 2018. Asynchronous programming with ranges - Ivan Čukić
C++ CoreHard Autumn 2018. Asynchronous programming with ranges - Ivan Čukić
corehard_by
 
C++ CoreHard Autumn 2018. Debug C++ Without Running - Anastasia Kazakova
C++ CoreHard Autumn 2018. Debug C++ Without Running - Anastasia KazakovaC++ CoreHard Autumn 2018. Debug C++ Without Running - Anastasia Kazakova
C++ CoreHard Autumn 2018. Debug C++ Without Running - Anastasia Kazakova
corehard_by
 
C++ CoreHard Autumn 2018. Полезный constexpr - Антон Полухин
C++ CoreHard Autumn 2018. Полезный constexpr - Антон ПолухинC++ CoreHard Autumn 2018. Полезный constexpr - Антон Полухин
C++ CoreHard Autumn 2018. Полезный constexpr - Антон Полухин
corehard_by
 
C++ CoreHard Autumn 2018. Text Formatting For a Future Range-Based Standard L...
C++ CoreHard Autumn 2018. Text Formatting For a Future Range-Based Standard L...C++ CoreHard Autumn 2018. Text Formatting For a Future Range-Based Standard L...
C++ CoreHard Autumn 2018. Text Formatting For a Future Range-Based Standard L...
corehard_by
 
Исключительная модель памяти. Алексей Ткаченко ➠ CoreHard Autumn 2019
Исключительная модель памяти. Алексей Ткаченко ➠ CoreHard Autumn 2019Исключительная модель памяти. Алексей Ткаченко ➠ CoreHard Autumn 2019
Исключительная модель памяти. Алексей Ткаченко ➠ CoreHard Autumn 2019
corehard_by
 
Как помочь и как помешать компилятору. Андрей Олейников ➠ CoreHard Autumn 2019
Как помочь и как помешать компилятору. Андрей Олейников ➠  CoreHard Autumn 2019Как помочь и как помешать компилятору. Андрей Олейников ➠  CoreHard Autumn 2019
Как помочь и как помешать компилятору. Андрей Олейников ➠ CoreHard Autumn 2019
corehard_by
 
Автоматизируй это. Кирилл Тихонов ➠ CoreHard Autumn 2019
Автоматизируй это. Кирилл Тихонов ➠  CoreHard Autumn 2019Автоматизируй это. Кирилл Тихонов ➠  CoreHard Autumn 2019
Автоматизируй это. Кирилл Тихонов ➠ CoreHard Autumn 2019
corehard_by
 

More from corehard_by (20)

C++ CoreHard Autumn 2018. Создание пакетов для открытых библиотек через conan...
C++ CoreHard Autumn 2018. Создание пакетов для открытых библиотек через conan...C++ CoreHard Autumn 2018. Создание пакетов для открытых библиотек через conan...
C++ CoreHard Autumn 2018. Создание пакетов для открытых библиотек через conan...
 
C++ CoreHard Autumn 2018. Что должен знать каждый C++ программист или Как про...
C++ CoreHard Autumn 2018. Что должен знать каждый C++ программист или Как про...C++ CoreHard Autumn 2018. Что должен знать каждый C++ программист или Как про...
C++ CoreHard Autumn 2018. Что должен знать каждый C++ программист или Как про...
 
C++ CoreHard Autumn 2018. Actors vs CSP vs Tasks vs ... - Евгений Охотников
C++ CoreHard Autumn 2018. Actors vs CSP vs Tasks vs ... - Евгений ОхотниковC++ CoreHard Autumn 2018. Actors vs CSP vs Tasks vs ... - Евгений Охотников
C++ CoreHard Autumn 2018. Actors vs CSP vs Tasks vs ... - Евгений Охотников
 
C++ CoreHard Autumn 2018. Знай свое "железо": иерархия памяти - Александр Титов
C++ CoreHard Autumn 2018. Знай свое "железо": иерархия памяти - Александр ТитовC++ CoreHard Autumn 2018. Знай свое "железо": иерархия памяти - Александр Титов
C++ CoreHard Autumn 2018. Знай свое "железо": иерархия памяти - Александр Титов
 
C++ CoreHard Autumn 2018. Информационная безопасность и разработка ПО - Евген...
C++ CoreHard Autumn 2018. Информационная безопасность и разработка ПО - Евген...C++ CoreHard Autumn 2018. Информационная безопасность и разработка ПО - Евген...
C++ CoreHard Autumn 2018. Информационная безопасность и разработка ПО - Евген...
 
C++ CoreHard Autumn 2018. Заглядываем под капот «Поясов по C++» - Илья Шишков
C++ CoreHard Autumn 2018. Заглядываем под капот «Поясов по C++» - Илья ШишковC++ CoreHard Autumn 2018. Заглядываем под капот «Поясов по C++» - Илья Шишков
C++ CoreHard Autumn 2018. Заглядываем под капот «Поясов по C++» - Илья Шишков
 
C++ CoreHard Autumn 2018. Ускорение сборки C++ проектов, способы и последстви...
C++ CoreHard Autumn 2018. Ускорение сборки C++ проектов, способы и последстви...C++ CoreHard Autumn 2018. Ускорение сборки C++ проектов, способы и последстви...
C++ CoreHard Autumn 2018. Ускорение сборки C++ проектов, способы и последстви...
 
C++ CoreHard Autumn 2018. Метаклассы: воплощаем мечты в реальность - Сергей С...
C++ CoreHard Autumn 2018. Метаклассы: воплощаем мечты в реальность - Сергей С...C++ CoreHard Autumn 2018. Метаклассы: воплощаем мечты в реальность - Сергей С...
C++ CoreHard Autumn 2018. Метаклассы: воплощаем мечты в реальность - Сергей С...
 
C++ CoreHard Autumn 2018. Что не умеет оптимизировать компилятор - Александр ...
C++ CoreHard Autumn 2018. Что не умеет оптимизировать компилятор - Александр ...C++ CoreHard Autumn 2018. Что не умеет оптимизировать компилятор - Александр ...
C++ CoreHard Autumn 2018. Что не умеет оптимизировать компилятор - Александр ...
 
C++ CoreHard Autumn 2018. Кодогенерация C++ кроссплатформенно. Продолжение - ...
C++ CoreHard Autumn 2018. Кодогенерация C++ кроссплатформенно. Продолжение - ...C++ CoreHard Autumn 2018. Кодогенерация C++ кроссплатформенно. Продолжение - ...
C++ CoreHard Autumn 2018. Кодогенерация C++ кроссплатформенно. Продолжение - ...
 
C++ CoreHard Autumn 2018. Concurrency and Parallelism in C++17 and C++20/23 -...
C++ CoreHard Autumn 2018. Concurrency and Parallelism in C++17 and C++20/23 -...C++ CoreHard Autumn 2018. Concurrency and Parallelism in C++17 and C++20/23 -...
C++ CoreHard Autumn 2018. Concurrency and Parallelism in C++17 and C++20/23 -...
 
C++ CoreHard Autumn 2018. Обработка списков на C++ в функциональном стиле - В...
C++ CoreHard Autumn 2018. Обработка списков на C++ в функциональном стиле - В...C++ CoreHard Autumn 2018. Обработка списков на C++ в функциональном стиле - В...
C++ CoreHard Autumn 2018. Обработка списков на C++ в функциональном стиле - В...
 
C++ Corehard Autumn 2018. Обучаем на Python, применяем на C++ - Павел Филонов
C++ Corehard Autumn 2018. Обучаем на Python, применяем на C++ - Павел ФилоновC++ Corehard Autumn 2018. Обучаем на Python, применяем на C++ - Павел Филонов
C++ Corehard Autumn 2018. Обучаем на Python, применяем на C++ - Павел Филонов
 
C++ CoreHard Autumn 2018. Asynchronous programming with ranges - Ivan Čukić
C++ CoreHard Autumn 2018. Asynchronous programming with ranges - Ivan ČukićC++ CoreHard Autumn 2018. Asynchronous programming with ranges - Ivan Čukić
C++ CoreHard Autumn 2018. Asynchronous programming with ranges - Ivan Čukić
 
C++ CoreHard Autumn 2018. Debug C++ Without Running - Anastasia Kazakova
C++ CoreHard Autumn 2018. Debug C++ Without Running - Anastasia KazakovaC++ CoreHard Autumn 2018. Debug C++ Without Running - Anastasia Kazakova
C++ CoreHard Autumn 2018. Debug C++ Without Running - Anastasia Kazakova
 
C++ CoreHard Autumn 2018. Полезный constexpr - Антон Полухин
C++ CoreHard Autumn 2018. Полезный constexpr - Антон ПолухинC++ CoreHard Autumn 2018. Полезный constexpr - Антон Полухин
C++ CoreHard Autumn 2018. Полезный constexpr - Антон Полухин
 
C++ CoreHard Autumn 2018. Text Formatting For a Future Range-Based Standard L...
C++ CoreHard Autumn 2018. Text Formatting For a Future Range-Based Standard L...C++ CoreHard Autumn 2018. Text Formatting For a Future Range-Based Standard L...
C++ CoreHard Autumn 2018. Text Formatting For a Future Range-Based Standard L...
 
Исключительная модель памяти. Алексей Ткаченко ➠ CoreHard Autumn 2019
Исключительная модель памяти. Алексей Ткаченко ➠ CoreHard Autumn 2019Исключительная модель памяти. Алексей Ткаченко ➠ CoreHard Autumn 2019
Исключительная модель памяти. Алексей Ткаченко ➠ CoreHard Autumn 2019
 
Как помочь и как помешать компилятору. Андрей Олейников ➠ CoreHard Autumn 2019
Как помочь и как помешать компилятору. Андрей Олейников ➠  CoreHard Autumn 2019Как помочь и как помешать компилятору. Андрей Олейников ➠  CoreHard Autumn 2019
Как помочь и как помешать компилятору. Андрей Олейников ➠ CoreHard Autumn 2019
 
Автоматизируй это. Кирилл Тихонов ➠ CoreHard Autumn 2019
Автоматизируй это. Кирилл Тихонов ➠  CoreHard Autumn 2019Автоматизируй это. Кирилл Тихонов ➠  CoreHard Autumn 2019
Автоматизируй это. Кирилл Тихонов ➠ CoreHard Autumn 2019
 

Recently uploaded

Using LLM Agents with Llama 3, LangGraph and Milvus
Using LLM Agents with Llama 3, LangGraph and MilvusUsing LLM Agents with Llama 3, LangGraph and Milvus
Using LLM Agents with Llama 3, LangGraph and Milvus
Zilliz
 
Patch Tuesday de julio
Patch Tuesday de julioPatch Tuesday de julio
Patch Tuesday de julio
Ivanti
 
Finetuning GenAI For Hacking and Defending
Finetuning GenAI For Hacking and DefendingFinetuning GenAI For Hacking and Defending
Finetuning GenAI For Hacking and Defending
Priyanka Aash
 
leewayhertz.com-Generative AI tech stack Frameworks infrastructure models and...
leewayhertz.com-Generative AI tech stack Frameworks infrastructure models and...leewayhertz.com-Generative AI tech stack Frameworks infrastructure models and...
leewayhertz.com-Generative AI tech stack Frameworks infrastructure models and...
alexjohnson7307
 
Use Cases & Benefits of RPA in Manufacturing in 2024.pptx
Use Cases & Benefits of RPA in Manufacturing in 2024.pptxUse Cases & Benefits of RPA in Manufacturing in 2024.pptx
Use Cases & Benefits of RPA in Manufacturing in 2024.pptx
SynapseIndia
 
Semantic-Aware Code Model: Elevating the Future of Software Development
Semantic-Aware Code Model: Elevating the Future of Software DevelopmentSemantic-Aware Code Model: Elevating the Future of Software Development
Semantic-Aware Code Model: Elevating the Future of Software Development
Baishakhi Ray
 
Camunda Chapter NY Meetup July 2024.pptx
Camunda Chapter NY Meetup July 2024.pptxCamunda Chapter NY Meetup July 2024.pptx
Camunda Chapter NY Meetup July 2024.pptx
ZachWylie3
 
Step-By-Step Process to Develop a Mobile App From Scratch
Step-By-Step Process to Develop a Mobile App From ScratchStep-By-Step Process to Develop a Mobile App From Scratch
Step-By-Step Process to Develop a Mobile App From Scratch
softsuave
 
UX Webinar Series: Essentials for Adopting Passkeys as the Foundation of your...
UX Webinar Series: Essentials for Adopting Passkeys as the Foundation of your...UX Webinar Series: Essentials for Adopting Passkeys as the Foundation of your...
UX Webinar Series: Essentials for Adopting Passkeys as the Foundation of your...
FIDO Alliance
 
It's your unstructured data: How to get your GenAI app to production (and spe...
It's your unstructured data: How to get your GenAI app to production (and spe...It's your unstructured data: How to get your GenAI app to production (and spe...
It's your unstructured data: How to get your GenAI app to production (and spe...
Zilliz
 
High Profile Girls call Service Pune 000XX00000 Provide Best And Top Girl Ser...
High Profile Girls call Service Pune 000XX00000 Provide Best And Top Girl Ser...High Profile Girls call Service Pune 000XX00000 Provide Best And Top Girl Ser...
High Profile Girls call Service Pune 000XX00000 Provide Best And Top Girl Ser...
bhumivarma35300
 
Mastering OnlyFans Clone App Development: Key Strategies for Success
Mastering OnlyFans Clone App Development: Key Strategies for SuccessMastering OnlyFans Clone App Development: Key Strategies for Success
Mastering OnlyFans Clone App Development: Key Strategies for Success
David Wilson
 
Mule Experience Hub and Release Channel with Java 17
Mule Experience Hub and Release Channel with Java 17Mule Experience Hub and Release Channel with Java 17
Mule Experience Hub and Release Channel with Java 17
Bhajan Mehta
 
The Impact of the Internet of Things (IoT) on Smart Homes and Cities
The Impact of the Internet of Things (IoT) on Smart Homes and CitiesThe Impact of the Internet of Things (IoT) on Smart Homes and Cities
The Impact of the Internet of Things (IoT) on Smart Homes and Cities
Arpan Buwa
 
Communications Mining Series - Zero to Hero - Session 3
Communications Mining Series - Zero to Hero - Session 3Communications Mining Series - Zero to Hero - Session 3
Communications Mining Series - Zero to Hero - Session 3
DianaGray10
 
Gen AI: Privacy Risks of Large Language Models (LLMs)
Gen AI: Privacy Risks of Large Language Models (LLMs)Gen AI: Privacy Risks of Large Language Models (LLMs)
Gen AI: Privacy Risks of Large Language Models (LLMs)
Debmalya Biswas
 
Russian Girls Call Navi Mumbai 🎈🔥9920725232 🔥💋🎈 Provide Best And Top Girl Ser...
Russian Girls Call Navi Mumbai 🎈🔥9920725232 🔥💋🎈 Provide Best And Top Girl Ser...Russian Girls Call Navi Mumbai 🎈🔥9920725232 🔥💋🎈 Provide Best And Top Girl Ser...
Russian Girls Call Navi Mumbai 🎈🔥9920725232 🔥💋🎈 Provide Best And Top Girl Ser...
bellared2
 
Garbage In, Garbage Out: Why poor data curation is killing your AI models (an...
Garbage In, Garbage Out: Why poor data curation is killing your AI models (an...Garbage In, Garbage Out: Why poor data curation is killing your AI models (an...
Garbage In, Garbage Out: Why poor data curation is killing your AI models (an...
Zilliz
 
Acumatica vs. Sage Intacct vs. NetSuite _ NOW CFO.pdf
Acumatica vs. Sage Intacct vs. NetSuite _ NOW CFO.pdfAcumatica vs. Sage Intacct vs. NetSuite _ NOW CFO.pdf
Acumatica vs. Sage Intacct vs. NetSuite _ NOW CFO.pdf
BrainSell Technologies
 
LeadMagnet IQ Review: Unlock the Secret to Effortless Traffic and Leads.pdf
LeadMagnet IQ Review:  Unlock the Secret to Effortless Traffic and Leads.pdfLeadMagnet IQ Review:  Unlock the Secret to Effortless Traffic and Leads.pdf
LeadMagnet IQ Review: Unlock the Secret to Effortless Traffic and Leads.pdf
SelfMade bd
 

Recently uploaded (20)

Using LLM Agents with Llama 3, LangGraph and Milvus
Using LLM Agents with Llama 3, LangGraph and MilvusUsing LLM Agents with Llama 3, LangGraph and Milvus
Using LLM Agents with Llama 3, LangGraph and Milvus
 
Patch Tuesday de julio
Patch Tuesday de julioPatch Tuesday de julio
Patch Tuesday de julio
 
Finetuning GenAI For Hacking and Defending
Finetuning GenAI For Hacking and DefendingFinetuning GenAI For Hacking and Defending
Finetuning GenAI For Hacking and Defending
 
leewayhertz.com-Generative AI tech stack Frameworks infrastructure models and...
leewayhertz.com-Generative AI tech stack Frameworks infrastructure models and...leewayhertz.com-Generative AI tech stack Frameworks infrastructure models and...
leewayhertz.com-Generative AI tech stack Frameworks infrastructure models and...
 
Use Cases & Benefits of RPA in Manufacturing in 2024.pptx
Use Cases & Benefits of RPA in Manufacturing in 2024.pptxUse Cases & Benefits of RPA in Manufacturing in 2024.pptx
Use Cases & Benefits of RPA in Manufacturing in 2024.pptx
 
Semantic-Aware Code Model: Elevating the Future of Software Development
Semantic-Aware Code Model: Elevating the Future of Software DevelopmentSemantic-Aware Code Model: Elevating the Future of Software Development
Semantic-Aware Code Model: Elevating the Future of Software Development
 
Camunda Chapter NY Meetup July 2024.pptx
Camunda Chapter NY Meetup July 2024.pptxCamunda Chapter NY Meetup July 2024.pptx
Camunda Chapter NY Meetup July 2024.pptx
 
Step-By-Step Process to Develop a Mobile App From Scratch
Step-By-Step Process to Develop a Mobile App From ScratchStep-By-Step Process to Develop a Mobile App From Scratch
Step-By-Step Process to Develop a Mobile App From Scratch
 
UX Webinar Series: Essentials for Adopting Passkeys as the Foundation of your...
UX Webinar Series: Essentials for Adopting Passkeys as the Foundation of your...UX Webinar Series: Essentials for Adopting Passkeys as the Foundation of your...
UX Webinar Series: Essentials for Adopting Passkeys as the Foundation of your...
 
It's your unstructured data: How to get your GenAI app to production (and spe...
It's your unstructured data: How to get your GenAI app to production (and spe...It's your unstructured data: How to get your GenAI app to production (and spe...
It's your unstructured data: How to get your GenAI app to production (and spe...
 
High Profile Girls call Service Pune 000XX00000 Provide Best And Top Girl Ser...
High Profile Girls call Service Pune 000XX00000 Provide Best And Top Girl Ser...High Profile Girls call Service Pune 000XX00000 Provide Best And Top Girl Ser...
High Profile Girls call Service Pune 000XX00000 Provide Best And Top Girl Ser...
 
Mastering OnlyFans Clone App Development: Key Strategies for Success
Mastering OnlyFans Clone App Development: Key Strategies for SuccessMastering OnlyFans Clone App Development: Key Strategies for Success
Mastering OnlyFans Clone App Development: Key Strategies for Success
 
Mule Experience Hub and Release Channel with Java 17
Mule Experience Hub and Release Channel with Java 17Mule Experience Hub and Release Channel with Java 17
Mule Experience Hub and Release Channel with Java 17
 
The Impact of the Internet of Things (IoT) on Smart Homes and Cities
The Impact of the Internet of Things (IoT) on Smart Homes and CitiesThe Impact of the Internet of Things (IoT) on Smart Homes and Cities
The Impact of the Internet of Things (IoT) on Smart Homes and Cities
 
Communications Mining Series - Zero to Hero - Session 3
Communications Mining Series - Zero to Hero - Session 3Communications Mining Series - Zero to Hero - Session 3
Communications Mining Series - Zero to Hero - Session 3
 
Gen AI: Privacy Risks of Large Language Models (LLMs)
Gen AI: Privacy Risks of Large Language Models (LLMs)Gen AI: Privacy Risks of Large Language Models (LLMs)
Gen AI: Privacy Risks of Large Language Models (LLMs)
 
Russian Girls Call Navi Mumbai 🎈🔥9920725232 🔥💋🎈 Provide Best And Top Girl Ser...
Russian Girls Call Navi Mumbai 🎈🔥9920725232 🔥💋🎈 Provide Best And Top Girl Ser...Russian Girls Call Navi Mumbai 🎈🔥9920725232 🔥💋🎈 Provide Best And Top Girl Ser...
Russian Girls Call Navi Mumbai 🎈🔥9920725232 🔥💋🎈 Provide Best And Top Girl Ser...
 
Garbage In, Garbage Out: Why poor data curation is killing your AI models (an...
Garbage In, Garbage Out: Why poor data curation is killing your AI models (an...Garbage In, Garbage Out: Why poor data curation is killing your AI models (an...
Garbage In, Garbage Out: Why poor data curation is killing your AI models (an...
 
Acumatica vs. Sage Intacct vs. NetSuite _ NOW CFO.pdf
Acumatica vs. Sage Intacct vs. NetSuite _ NOW CFO.pdfAcumatica vs. Sage Intacct vs. NetSuite _ NOW CFO.pdf
Acumatica vs. Sage Intacct vs. NetSuite _ NOW CFO.pdf
 
LeadMagnet IQ Review: Unlock the Secret to Effortless Traffic and Leads.pdf
LeadMagnet IQ Review:  Unlock the Secret to Effortless Traffic and Leads.pdfLeadMagnet IQ Review:  Unlock the Secret to Effortless Traffic and Leads.pdf
LeadMagnet IQ Review: Unlock the Secret to Effortless Traffic and Leads.pdf
 

строим Microkernel architecture на базе паттерна pipes and filters

  • 1. Microkernel Architecture based on Pipes and Filters Anton Semenchenko
  • 2. About myself  Co-creator of communities www.COMAQA.BY and www.CoreHard.by, co- founder of company www.DPI.Solutions, «tricky» manager at EPAM Systems.
  • 3. Agenda 1. Idea 2. History 3. Microkernel Architecture 4. Pipes and Filters 5. Microservices Architecture 6. Summary 7. Examples 8. Quality assurance 9. What’s next 10.Books 11.Engineers from 70-s
  • 4. Idea 1. Everything new - is totally forgotten old things 2. Study, study and study once again 3. Read books 4. Think about the idea, and do not drown in tons of terminology and positioning slogans
  • 5. History  1. Microkernel Architecture conception – 1960-s 2. Pipes and Filters conception – 1960-s 3. UNIX – 1970 (+ Dennis MacAlistair Ritchie) 4. UNIX pipeline – 1973 (Malcolm Douglas McIlroy) 5. Component-based software engineering – 1987 (Niklaus Emil Wirth) 6. Component-based unification – 1989 (Bertrand Meyer) 7. COM – 1993 8. CORBA – 1990-s 9. SOAP – 1990-s 2000-s 10.JavaBeans 11..Net components 12.Microservices initial definition – 2005 13.Microservices Architecture - 2012 14.PowerShells
  • 7. Introduction 1. The Microkernel architectural pattern applies to software systems that must be able to adapt to changing system requirements. 2. It separates a minimal functional core from extended functionality and customer specific parts. 3. The microkernel also serves as a socket for plugging in these extensions and coordinating their collaboration. 4. Microkernel systems have mainly been described in relation to the design of operating systems. However, this pattern is also mainly applicable to other domains, e.g. financial applications and database systems.
  • 8. Challange 1. How to design an architecture for the development of several applications with similar programming interfaces that build on the same core functionality.
  • 9. Context 1. Developing software for an application domain that needs to cope with a broad spectrum of similar standards and technologies is a nontrivial task. 2. Well-known examples are application platforms such as operating systems and graphical user interfaces. 3. Such systems often have a long life-span, often ten years or more. 4. Over time periods of this length, new technologies emerge and old ones change.
  • 10. Context 5. Some applications exist in multiple versions. – Each version offers a different set of functionality to its users, or differs from other versions in specific aspects, such as its user interface. – Despite their differences, however, all versions of the application should be based on a common architecture and functional core. 6. The goal is to avoid architectural drift between the versions of the application and to minimize development and maintenance effort for shared functionality. 7. It should be easy to provide a particular application version with different user interfaces, and also to run the version on different platforms.
  • 11. “Features” 1. The application platform must cope with continuous hardware and software evolution. 2. The application platform should be portable, extensible and adaptable to allow easy integration of emerging technologies. 3. The success of such application platforms may also depend on their capability to run applications written for existing standards. 4. To support a broad range of applications, there is a need for more than one view of the functionality of the underlying application platform. 5. Ideally, an application platform (such as an operating system or a database) should also be able to emulate other application platforms that belong to the same application domain.
  • 12. Solution 1. Compose different versions of the application by extending a common but minimal core via a “plug-and-play” infrastructure. 2. The Microkernel pattern defines five kinds of participating components: • Microkernel • Internal servers • External servers • Adapters • Clients
  • 13. Solution 3. The microkernel implements the fundamental functionality shared by all application versions and provides the infrastructure for integrating version specific functionality. 4. Internal servers implement version specific core functionality, and external servers version specific user interfaces or APIs. 5. A specific application version is configured by connecting the corresponding internal servers with the microkernel, and providing appropriate external servers to access its functionality. 6. Consequently, all versions of the application share a common functional and infrastructural core, but provide a tailored function set and look-and-feel.
  • 14. Solution 7. Clients, whether human or other software systems, access the microkernel’s functionality solely via the interfaces or APIs provided by the external servers, which forward all requests they receive to the microkernel. 8. If the microkernel implements the requested function itself, it executes the function, otherwise it routes the request to the corresponding internal server. 9. Results are returned accordingly so that the external servers can display or deliver them to the client.
  • 15. Solution 10. A problem arises if a client needs to access the interfaces of its external server directly. • – Every communication with an external server must be hardcoded into the client code. • – Such a tight coupling between clients and servers does not support changeability very well. 10. We therefore introduce interfaces between clients and their external servers to protect clients from direct dependencies. 11. Adapters represent these interfaces between clients and their external servers, and allow clients to access the services of their external server in a portable way..
  • 16. Tech details 1. The internal structure of the microkernel is typically based on Layers. • – The bottommost layer abstracts from the underlying system platform, thereby supporting the portability of all higher levels. • – The second layer implements infrastructure functionality, such as resource management, on which the microkernel depends. • – The layer above hosts the domain functionality that is shared by all application versions. • – The topmost layer includes the mechanisms for configuring internal servers with the microkernel, as well as for routing requests from external servers to their intended recipient.
  • 17. Tech details 2. The microkernel should be kept as small a s possible to reduce memory requirements and provide mechanisms that execute quickly. • – Additional and more complex services are therefore implemented by internal servers that the microkernel activates or loads only when necessary.
  • 18. Internal and External Server 1. Internal servers can be considered extensions of the microkernel and are only accessible by the microkernel component. 2. Internal servers may be implemented as separate processes or as shared libraries: • – Graphics card drivers are developed as shared libraries because they only act on behalf of clients. • – In contrast, page fault handlers are separate processes. They always have to remain in main memory and cannot be swapped to external storage. 3. Internal servers follow a similar Layers design as the microkernel, but do not usually provide a routing layer. 4. Each external server is implemented as a separate process that provides its own service interface. The internal architecture of an external server depends on the policies it comprises.
  • 19. Benefits 1. Portability. A Microkernel system offers a high degree of portability, for two reasons: • – In most cases you do not need to port external servers or client applications if you port the Microkernel system to a new software or hardware environment. • – Migrating the microkernel to a new hardware environment only requires modifications to the hardware-dependent parts of the microkernel and does not affect external servers. 2. Flexibility and Extensibility. • – If you need to implement an additional view, all you need to do is add a new external server. • – Extending the system with additional capabilities only requires the addition or extension of internal servers
  • 20. Benefits 3. Separation of policy and mechanism. • – The microkernel component provides all the mechanisms necessary to enable external servers to implement their policies. • – This strict separation of policies and mechanisms increases the maintainability and changeability of the whole system • – It also allows you to add new external servers that implement their own specialized views. If the microkernel component were to implement policies, this would unnecessarily limit the views that could be implemented by external servers.
  • 21. Benefits 4. Scalability. • – A distributed Microkernel system is applicable to the development of operating systems or database systems for computer networks, or multiprocessors with local memory. • – If your Microkernel system works on a network of machines, it is easy to scale the Microkernel system to the new configuration when you add a new machine to the network. 3. Transparency. • – In a distributed system components can be distributed over a network of machines. • – In such a configuration, the Microkernel architecture allows each component to access other components without needing to know their location. All details of inter-process communication with servers are hidden from clients by the adapters and the microkernel.
  • 22. Limitations drawbacks 1. Performance. • – A monolithic software system designed to offer a specific view will generally have better performance than a Microkernel system supporting different views. • – We therefore have to pay a price for flexibility and extensibility. • – If the communication within the Microkernel system is optimized for performance, however, this price can be small
  • 23. Limitations drawbacks 2. Complexity of design and implementation. • – Developing a Microkernel-based system is a non-trivial task. • – For example, it can sometimes be very difficult to analyze or predict the basic mechanisms a microkernel component must provide. • – In addition, the separation between mechanisms and policies requires in-depth domain knowledge and considerable effort during requirements analysis and design
  • 25. Introduction 1. The Pipes and Filters architectural pattern provides a structure for systems that process a stream of data. 2. Each processing step is encapsulated in a filter component. 3. Data is passed through pipes between adjacent filters. 4. Recombining filters allows you to build families of related systems.
  • 26. Example 1. Suppose we want to develop a new compiler for the Java  programming language. 2. We want the compiler to produce either optimized byte-code to run on a JVM, or optimized machine code to run natively on various platforms • – Similar to the GNU GCJ compiler. 3. A backend will translate byte-code into the machine instructions of a specific processor for best performance. 4. Conceptually, translation from Java to byte-code consists of the phases lexical analysis, syntax analysis, semantic analysis, byte-code generation, byte-code optimization, and optionally machine-code generation. 5. Each stage has well-defined input and output data.
  • 28. Challange 1. How to provide a design that is suitable for processing data streams.
  • 29. Context 1. Some applications process streams of data. • – Input data streams are transformed stepwise into output data streams. 2. However, using common and familiar request/ response semantics for structuring such types of application is typically impractical. 3. Instead we must specify an appropriate data flow model for them.
  • 30. Context 4. Modeling a data-flow-driven application raises some non- trivial developmental and operational challenges. 5. First, the parts of the application should correspond to discrete and distinguishable actions on the data flow. 6. Second, some usage scenarios require explicit access to intermediate yet meaningful results. 7. Third, the chosen data flow model should allow applications to read, process, and write data streams incrementally rather than wholesale and sequentially so that throughput is maximized. 8. Lastly, long-duration processing activities must not become a performance bottleneck.
  • 31. “Features” 1. Future system enhancements should be possible by exchanging processing steps or by recombination of steps, even by users. 2. Small processing steps are easier to reuse in different contexts than large components. 3. Non-adjacent processing steps do not share information. 4. Different sources of input data exist, such as a network connection or a hardware sensor providing temperature readings, for example. 5. It should be possible to present or store final results in various ways. 6. Explicit storage of intermediate results for further processing in files clutters directories and is error-prone, if done by users. 7. You may not want to rule out multi-processing the steps, for example running them in parallel or quasi-parallel.
  • 32. Solution 1. The Pipes and Filters architectural pattern divides the task of a system into several sequential processing steps. 2. These steps are connected by the data flow through the system. The output data of a step is the input to the subsequent step. 3. Each processing step is implemented by a filter component. 4. A filter consumes and delivers data incrementally, in contrast to consuming all its input before producing any output, to achieve low latency and enable real parallel processing
  • 33. Solution 5. The input to the system is provided by a data source such as a text file. The output flows into a data sink such as a file, terminal, animation program and so on. 6. The data source, the filters and the data sink are connected sequentially by pipes that buffer data. 7. Each pipe implements the data flow between adjacent processing steps. 8. The sequence of filters combined by pipes is called a processing pipeline
  • 35. Solution 9. In a single-process arrangement, pipes are typically implemented as queues. 10. In a distributed arrangement, pipes are realized as some form of messaging infrastructure that passes data streams between remote filters. 11. If a filter performs a long-duration activity, consider integrating multiple parallel instances of the filter into the processing chain. • Such a configuration can further increase system performance and throughput, as some filter instances can start processing new data streams while others are processing previous data streams.
  • 36. Filter Tech details 1. Filter components are the processing units of the pipeline. 2. A filter enriches data by computing and adding information, refines data by concentrating or extracting information, and transforms data by delivering the data in some other representation. A concrete filter implementation may combine any of these three basic principles. 3. An active filter starts processing on its own as a separate program or thread. Most commonly, the filter is active in a loop, pulling its input from and pushing its output down the pipeline. 4. A passive filter component is activated by being called either as a function (pull) or as a procedure (push).
  • 37. Pipe Tech details 1. Pipes denote the connections between filters, between the data source and the first filter, and between the last filter and the data sink. 2. If two active components are joined, the pipe synchronizes them. This synchronization is done with a first-in-first-out buffer (queue). 3. If activity is controlled by one of the adjacent filters, the pipe can be implemented by a direct call from one filter to the next. Direct calls make filter recombination harder, however.
  • 38. Options 1. The single-input single-output filter specification of the Pipes and Filters pattern can be varied to allow filters with more than one input and/or more than one output. 2. Processing can then be set up a s a directed graph that can even contain feedback loops. • – The design of such a system, especially one with feedback loops, requires a solid foundation to explain and understand the complete calculation. • – A rigorous theoretical analysis and specification using formal methods are appropriate, to prove that the system terminates and produces the desired result. 3. If we restrict ourselves to simple directed acyclic graphs, however, it is still possible to build useful systems.
  • 39. Benefits 1. A Pipes and Filters architecture decouples different data processing steps so that they can evolve independently of one another and support an incremental data processing approach. 2. Pipes and Filters provides for flexibility by exchanging or reordering the processing steps. 3. Recombining filters allows you to build families of related systems using existing processing components.
  • 40. Benefits 4. Applicability • Whether a separation into processing steps is feasible strongly depends on the application domain and the problem to be solved. For example, an interactive, event-driven system does not split into sequential stages.
  • 42. Context Just a popular context 1. Server-side enterprise application. 2. A variety of different clients support • Desktop browsers • Mobile browsers • Native mobile applications 3. Expose an API for 3rd parties to consume 4. Integrate with other applications via either web services or a message broker 5. Handles requests (HTTP requests and messages) by executing business logic; accessing a database; exchanging messages with other systems; and returning a HTML/JSON/XML response. 6. There are logical components corresponding to different functional areas of the application.
  • 43. “Features” 1. There is a team of developers working on the application 2. New team members must quickly become productive 3. The application must be easy to understand and modify 4. You want to practice continuous deployment of the application 5. You must run multiple copies of the application on multiple machines in order to satisfy scalability and availability requirements 6. You want to take advantage of emerging technologies (frameworks, programming languages, etc)
  • 45. Solution 1. Define an architecture that structures the application as a set of loosely coupled, collaborating services. This approach corresponds to the Y-axis of the Scale Cube. Each service implements a set of narrowly, related functions. For example, an application might consist of services such as the order management service, the customer management service etc. 2. Services communicate using either synchronous protocols such as HTTP/REST or asynchronous protocols such as AMQP. Services can be developed and deployed independently of one another. Each service has its own database in order to be decoupled from other services. Data consistency between services is maintained using an event-driven architecture
  • 48. Summary 1. Everything new - is totally forgotten old things 2. Study, study and study once again 3. Read books 4. Think about the idea, and do not drown in tons of terminology and positioning slogans 5. Microkernel, Pipes and Filters, Microservicies – great Architectural options
  • 50. UNIX philosophy by Malcolm 1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". 2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input. 3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them. 4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.
  • 51. DSL based solutions 1. Health insurance for USA and Canada 2. The world leader of Hardware production • Trains and wagons “management” • Calculation, optimization, rule based option selection for electrical networks • Note: super- general cores and DSL configurations 3. Paper’s advertisement for USA
  • 52. DSL based - video 1. Analyst Days 2015. Антон Наумович. Роль бизнес- аналитика в разработке собственной Business Rule Engine с нуля как основной платформы проекта 2. Юрий Русович. Особенности системного анализа особо крупных проектов построенных на базе Business Rule Engine «Drools» 3. Александр Василенок. XText – Business Rule Engine в контексте бизнес-анализа 4. Антон Семенченко. BDD or DSL как способ построения коммуникации на проекте 5. Антон Наумович. Разработка своей agile методологии для управления крупными проектами
  • 53. Let’s vote ???  1. Microkernel? 2. Microservices? 3. Pipes and Filters ..?
  • 54. Example EPAM Report Portal • Transition from Monolithic solution to Microservicies architecture
  • 55. Architecture – Methodology 1. Антон Наумович. Разработка своей agile методологии для управления крупными проектами 2. When it’s worth moving from Agile to Waterfall
  • 57. Examples 1. Unix philosophy 2. Health insurance for USA and Canada 3. The world leader of Hardware production • Trains and wagons “management” • Calculation, optimization, rule based option selection for electrical networks 3. Paper’s advertisement for USA 4. EPAM Report Portal
  • 59. Books
  • 60. Examples • «Pattern-Oriented Software Architecture» Volume 1-3 Notes: I highly recommend to read it from start to the very end. • «Domain Specific Languages» Martin Fowler Notes: I highly recommend to read it from start to the very end. • «Patterns of Enterprise Application Architecture» Martin Fowler Notes: I highly recommend to read it from start to the very end. • «The Pragmatic Programmer: From Journeyman to Master» D.Thomas, A. Hunt Notes: A great book, consisting a whole diversity of atomic advise. IMHO required to be read from the beginning to the end twice and then look through various chapters when preparing to the interview or discussion with the customer.
  • 62. Dennis MacAlistair Ritchie 1. C 2. Unix 3. Dozens of brilliant inventions
  • 63. Malcolm Douglas McIlroy 1. Unix pipelines 2. Software componentry 3. Dozens of Unix utilities
  • 64. Niklaus Emil Wirth 1. Pascal 2. Component-based software engineering 3. Dozens of brilliant inventions
  • 65. Bertrand Meyer 1. Component-based unification 2. Dozens of brilliant inventions 3. Innopolis University lecturer (Russia)
  • 66. Thanks! Questions? Anton Semenchenko skype: dpi.semenchenko semenchenko@dpi.solutions