tanszek:oktatas:iss_t:object_request_broker
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| tanszek:oktatas:iss_t:object_request_broker [2026/03/01 17:44] – [Object Request Broker (ORB)] knehez | tanszek:oktatas:iss_t:object_request_broker [2026/03/01 17:58] (current) – [Object Request Broker (ORB)] knehez | ||
|---|---|---|---|
| Line 20: | Line 20: | ||
| Conceptually: | Conceptually: | ||
| - | Client -> ORB -> Remote Object | + | < |
| - | + | sequenceDiagram | |
| - | Remote Object | + | Client->>ORB: Method call |
| + | ORB->> | ||
| + | RemoteObject-->>ORB: Return result | ||
| + | ORB-->>Client: Return response | ||
| + | </ | ||
| The ORB handles all low-level details such as transport protocols and data encoding. | The ORB handles all low-level details such as transport protocols and data encoding. | ||
| + | |||
| + | ---- | ||
| + | |||
| + | ==== Distributed Objects Concept ==== | ||
| + | |||
| + | CORBA extends object-oriented principles to distributed environments. | ||
| + | |||
| + | Remote objects: | ||
| + | |||
| + | * expose methods, | ||
| + | * encapsulate data, | ||
| + | * can be invoked across networks. | ||
| + | |||
| + | Unlike REST (which is resource-based) or JSON-RPC (which is procedure-based), | ||
| + | |||
| + | This design reflects classic OOP thinking in distributed systems. | ||
| + | ---- | ||
| + | ==== IDL – Interface Definition Language ==== | ||
| + | |||
| + | CORBA introduced a language-independent interface definition mechanism called IDL (Interface Definition Language). | ||
| + | |||
| + | IDL allows developers to define object interfaces independently of programming languages. | ||
| + | |||
| + | Example IDL: | ||
| + | |||
| + | <sxh> | ||
| + | interface Calculator { | ||
| + | long add(in long a, in long b); | ||
| + | }; | ||
| + | </ | ||
| + | |||
| + | From this IDL definition, language-specific stubs and skeletons are generated automatically (e.g., for C++, Java, Python). | ||
| + | |||
| + | This ensures: | ||
| + | |||
| + | * language interoperability | ||
| + | * strict interface contracts | ||
| + | * platform independence | ||
| + | |||
| + | IDL was one of the early solutions to cross-language service integration. | ||
| + | |||
| + | CORBA IDL supports interface inheritance, | ||
| + | This enables the reuse of method definitions and supports polymorphism in distributed systems. | ||
| + | |||
| + | Below is an example from a simplified employee management system. | ||
| + | |||
| + | < | ||
| + | module Company { | ||
| + | |||
| + | interface Person { | ||
| + | | ||
| + | long getId(); | ||
| + | }; | ||
| + | |||
| + | interface Employee : Person { | ||
| + | | ||
| + | void setSalary(in double newSalary); | ||
| + | }; | ||
| + | |||
| + | interface Manager : Employee { | ||
| + | void addTeamMember(in Person p); | ||
| + | }; | ||
| + | |||
| + | }; | ||
| + | </ | ||
| + | |||
| + | |||
| + | ---- | ||
| + | ==== 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, | ||
| + | |||
| + | **Marshalling**: | ||
| + | converting objects or parameters into a platform-independent serialized format for transmission. | ||
| + | |||
| + | **Unmarshalling**: | ||
| + | reconstructing the original objects from the serialized data on the receiving side. | ||
| + | |||
| + | This ensures that data types remain consistent across systems, different hardware architectures can communicate, | ||
| + | ---- | ||
| + | |||
| + | |||
| + | ==== 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 ==== | ||
| + | |||
| + | Despite its strong architectural design, CORBA gradually declined due to: | ||
| + | |||
| + | * high complexity | ||
| + | * steep learning curve | ||
| + | * heavyweight configuration | ||
| + | * firewall/ | ||
| + | * verbose tooling | ||
| + | * rise of simpler HTTP-based APIs (REST) | ||
| + | |||
| + | Tutorial: https:// | ||
tanszek/oktatas/iss_t/object_request_broker.1772387043.txt.gz · Last modified: 2026/03/01 17:44 by knehez
