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 [2023/05/26 06:25] – [Object-Oriented Programming OOP] 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 75: | Line 66: | ||
| - | - architecture principles | + | * architecture principles |
| - | - SOLID | + | |
| - | - Single-responsibiity Principle | + | |
| - | - | + | |
| - | - Open-Cosed | + | |
| - | - | + | |
| - | - Liskov substitution principles | + | * client should NOT implement interfaces / methods they dont use |
| - | - Interface segregation principle | + | |
| - | - client should NOT implement interfaces / methods they dont use | + | |
| - | - Dependency Inversion principle | + | |
| - | - | ||
| Line 187: | Line 176: | ||
| Method overloading is an example of **static polymorphism**. | 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> | <sxh java> | ||
| Line 207: | Line 198: | ||
| } | } | ||
| </ | </ | ||
| + | |||
| + | |||
| + | |||
| + | ===== Async programming ===== | ||
| + | |||
| + | Exlained with Python | ||
| + | |||
| + | by re-implementing " | ||
| + | |||
| + | https:// | ||
| + | |||
| + | |||
devops/software_architecture.1685082305.txt.gz · Last modified: by skipidar
