Differences

This shows you the differences between two versions of the page.

--- tanszek:oktatas:iss_t:object_request_broker [2026/03/01 17:46] – [4. IDL – Interface Definition Language] knehez
+++ tanszek:oktatas:iss_t:object_request_broker [2026/03/01 17:58] (current) – [Object Request Broker (ORB)] knehez
@@ Line 20: / Line 20: @@
 Conceptually:
-Client -> ORB -> Remote Object
+<mermaid>
+sequenceDiagram
-Remote Object -> ORB -> Client
+Client->>ORB: Method call
+ORB->>RemoteObject: Forward request
+RemoteObject-->>ORB: Return result
+ORB-->>Client: Return response
+</mermaid>
 The ORB handles all low-level details such as transport protocols and data encoding.
+----
 ==== Distributed Objects Concept ====
@@ Line 39: / Line 45: @@
 This design reflects classic OOP thinking in distributed systems.
+----
-==== 4. IDL – Interface Definition Language ====
+==== IDL – Interface Definition Language ====
 CORBA introduced a language-independent interface definition mechanism called IDL (Interface Definition Language).
@@ Line 64: / Line 70: @@
 IDL was one of the early solutions to cross-language service integration.
+CORBA IDL supports interface inheritance, allowing one interface to extend another.
+This enables the reuse of method definitions and supports polymorphism in distributed systems.
+Below is an example from a simplified employee management system.
+<sxh>
+module Company {
+interface Person {
+   string getName();
+   long getId();
+};
+interface Employee : Person {
+   double getSalary();
+   void setSalary(in double newSalary);
+};
+interface Manager : Employee {
+   void addTeamMember(in Person p);
+};
+};
+</sxh>
+----
 ==== Marshalling and Unmarshalling ====
 CORBA introduced standardized marshalling and unmarshalling mechanisms.
+This mechanism is essential in distributed systems because memory representations differ across:
+  * programming languages
+  * operating systems
+  * CPU architectures (32-bit vs 64-bit, little-endian vs big-endian)
+  * Without marshalling, raw in-memory data could not be safely transmitted between heterogeneous systems.
 **Marshalling**:
@@ Line 74: / Line 114: @@
 reconstructing the original objects from the serialized data on the receiving side.
-This ensures that:
+This ensures that data types remain consistent across systems, different hardware architectures can communicate, and programming language differences are abstracted.
+----
+==== Service Registry Concept ====
+CORBA introduced early ideas similar to a service registry.
+Objects could register themselves in a naming service, allowing clients to discover them dynamically.
+This resembles:
+  * modern service discovery systems (e.g., Consul, Eureka),
+  * DNS-based service resolution,
+  * microservice registries.
+Services were browsable in a uniform manner, which was advanced for its time.
+----
+==== Known Implementations ====
+Well-known CORBA implementations include:
+  * ORBix
+  * VisiBroker
+  * TAO
+Java-based CORBA implementations
+  * Java RMI (conceptually related, though not CORBA-based)
+CORBA support has historically been included in enterprise application servers such as:
+  * JBoss
+  * IBM WebSphere
+Although less common today, CORBA is still present in:
+  * banking systems,
+  * telecommunications,
+  * aerospace and defense systems,
+  * legacy enterprise infrastructures.
+----
+==== Why CORBA Declined ====
-  * data types remain consistent across systems,
+Despite its strong architectural design, CORBA gradually declined due to:
-  * different hardware architectures can communicate,
-  * programming language differences are abstracted.
-Modern equivalents include:
+  * high complexity
+  * steep learning curve
+  * heavyweight configuration
+  * firewall/NAT issues
+  * verbose tooling
+  * rise of simpler HTTP-based APIs (REST)
-  * JSON serialization (REST),
+Tutorial: https://medium.com/@diremund/understanding-corba-building-a-banking-system-with-java-47c67fc42a66
-  * Protocol Buffers (gRPC),
-  * binary encoding in RPC frameworks.