devops:software_architecture
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
devops:software_architecture [2018/04/06 10:17] – skipidar | devops:software_architecture [2024/01/11 09:09] (current) – skipidar | ||
---|---|---|---|
Line 43: | Line 43: | ||
- | - Java RMI | + | * Java RMI |
- | - RMI you can have references to remote objects and invoke their methods | + | |
RMI stands out when the need to develop something more complex than a pure client-server architecture arises | RMI stands out when the need to develop something more complex than a pure client-server architecture arises | ||
- | - Java RPC | + | * Java RPC |
- | - With RPC you can just call remote functions exported into a server, | + | |
- | In Java, when you talk about RPC, you are talking about SOAP and Web Services. | + | |
- | + | * SOAP - "Simple Object Access Protocol" | |
- | Lost its popularity, REST is the solution of choice. | + | |
- | + | ||
- | + | ||
- | - SOAP | + | |
- | Simple Object Access Protocol | + | |
- | - If you need ACID-compliant transactions, | + | |
- | - | + | |
- | + | ||
- CORBA | - CORBA | ||
-Common Object Request Broker Architecture | -Common Object Request Broker Architecture | ||
- | - REST | + | * REST - Representational state transfer. The general consensus among experts these days is that REST is the typically preferred protocol unless there’s a compelling reason to use SOAP |
- | Representational state transfer | + | |
- | The general consensus among experts these days is that REST is the typically preferred protocol unless there’s a compelling reason to use SOAP | + | * Simple |
- | - REST allows a greater variety of data formats, whereas SOAP only allows XML. | + | |
- | - SImple | + | |
- | - uses HTTP layer | + | |
Line 74: | Line 65: | ||
- | |||
- | - Architectures on AWS | ||
- | - | ||
- | |||
- | |||
- | - Swagger vs. OPenAPI | ||
- | - OpenAPI = Specification | ||
- | - Swagger = Tools for implementing the specification | ||
- | + | * architecture principles | |
- | - structure data | + | |
- | - | + | |
- | + | | |
- | + | | |
- | - SaaS application | + | |
- | - | + | * client should NOT implement interfaces / methods they dont use |
- | + | | |
- | + | ||
- | - architecture principles | + | |
- | - SOLID | + | |
- | - Single-responsibiity Principle | + | |
- | - | + | |
- | - Open-Cosed | + | |
- | - | + | |
- | - Liskov substitution principles | + | |
- | - Interface segregation principle | + | |
- | - client should NOT implement interfaces / methods they dont use | + | |
- | - Dependency Inversion principle | + | |
- | - | ||
+ | - 4+1 View: https:// | ||
+ | |||
+ | * 1 Logical View | ||
+ | * Diagram: https:// | ||
+ | * Diagram2: https:// | ||
+ | * Diagram3: https:// | ||
+ | |||
+ | |||
+ | * 2 Development view | ||
+ | * Diagram: https:// | ||
+ | |||
+ | |||
+ | * 3 Process view | ||
+ | * Diagram: https:// | ||
+ | |||
+ | |||
+ | |||
+ | * 4 Physical view / deployment view | ||
+ | * Diagram: https:// | ||
+ | |||
+ | * +1 Scenarios | ||
+ | * Diagram: https:// | ||
+ | |||
+ | |||
+ | |||
+ | ===== Object-Oriented Programming OOP ===== | ||
+ | |||
+ | === Polymorphism === | ||
+ | |||
+ | Polymorphism in Java has two types: | ||
+ | |||
+ | Runtime polymorphism (dynamic binding) and Compile time polymorphism (static binding). | ||
+ | |||
+ | Method overriding is an example of dynamic polymorphism, | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | === Binding === | ||
+ | |||
+ | <color # | ||
+ | |||
+ | <color # | ||
+ | |||
+ | <color # | ||
+ | |||
+ | <sxh java> | ||
+ | class Dog { | ||
+ | public void bark(){ | ||
+ | System.out.println(" | ||
+ | } | ||
+ | } | ||
+ | class Hound extends Dog { | ||
+ | public void bark(){ | ||
+ | System.out.println(" | ||
+ | } | ||
+ | } | ||
+ | |||
+ | |||
+ | |||
+ | public class OverridingTest1 { | ||
+ | public static void main(String [] args){ | ||
+ | Dog dog = new Dog(); // var of type dog resolves method bark at runtime | ||
+ | dog.bark(); // dog bark | ||
+ | } | ||
+ | } | ||
+ | |||
+ | public class OverridingTest2 { | ||
+ | public static void main(String [] args){ | ||
+ | Dog dog = new Hound(); // use Hound, where method bark is overridden | ||
+ | dog.bark(); // hound bark. var of type dog resolves method bark at runtime | ||
+ | } | ||
+ | } | ||
+ | |||
+ | </ | ||
+ | |||
+ | |||
+ | |||
+ | === Method Overriding === | ||
+ | |||
+ | Method overriding is an example of **dynamic polymorphism**. | ||
+ | |||
+ | Method overriding, in object-oriented programming, | ||
+ | |||
+ | <sxh java> | ||
+ | class Dog { | ||
+ | public void bark(){ | ||
+ | System.out.println(" | ||
+ | } | ||
+ | } | ||
+ | class Hound extends Dog { | ||
+ | public void bark(){ | ||
+ | System.out.println(" | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | === Method Overloading === | ||
+ | |||
+ | Method overloading is an example of **static polymorphism**. | ||
+ | |||
+ | Method overloading in java is a feature that allows a class to have **more than one method with the same name**, but with **different parameters** | ||
+ | |||
+ | <sxh java> | ||
+ | public void Square ( int number ) | ||
+ | { | ||
+ | int square = number * number; | ||
+ | System.out.printIn(“Method with Integer Argument Called: | ||
+ | } | ||
+ | public void Square(double number) | ||
+ | { | ||
+ | double square = number * number; | ||
+ | System.out.printIn(“Method with double Argument Called: | ||
+ | } | ||
- | - IoT protocols | + | public void Square(long number) |
- | - MQTT | + | { |
- | - Public | + | long square = number * number; |
+ | System.out.printIn(“Method with long Argument Called: | ||
+ | } | ||
+ | </sxh> | ||
- | - DONE Terraform | ||
- | - NOT provider agnositc. The syntaxis is different for all providers. | ||
- | - INtrastructure management | ||
- | - Configuration management | ||
+ | ===== Async programming ===== | ||
+ | Exlained with Python | ||
+ | by re-implementing " | ||
+ | https:// | ||
- | - interface strategy and support build up of the partner integrations | ||
- | - business needs into technical requirements | ||
- | - Make sure that the solutions meet the requirements in regard to security and availability | ||
- | - DevOps culture and infrastructure |
devops/software_architecture.1523009871.txt.gz · Last modified: (external edit)