CSE119 Component Based Technology

UNIT – IV Java and CORBA Interface Definition Language Object Request Broker System Object Model Portable Object Adapter CORBA services CORBA Component Model

Java and CORBA An important reason to incorporate CORBA into Java projects is to enable the use of IIOP for communication with non-Java subsystems. For access to CORBA services it is usually more convenient to go through Java-specific access interfaces that can map to CORBA-compliant and other service implementations. Several of these Java service interface standards. CORBA and Java usually coexist in almost all application server products today. It is therefore often reasonable to assume the presence of CORBA mechanisms (for interoperation) when implementing for the application server tier. RMI is normally implemented using a proprietary protocol (Java Remote Method Protocol – JRMP), which limits the use of RMI to Java-to-Java com- munication.

Java and CORBA The RMI-over-IIOP specification was introduced in 1999 and is part of the JDK since J2SE 1.3. It supports a restricted RMI variant to be used over the CORBA IIOP protocol, reaching any CORBA 2.4-compliant ORB. This specification requires a recent addition to CORBA that enables the sending of objects by value – that is, the sending of a copy of the object rather than the sending of a reference to the object staying behind. RMI-over-IIOP does not support the RMI distributed garbage collection model and thus falls back on CORBA’s lifecycle management approach to deal with the lifetime of remote objects explicitly.

Java and CORBA In addition, RMI-over-IIOP creates proxies that do not allow normal Java instanceof/cast mechanisms to be used to discover interfaces or subclasses. Instead, a service method must be called to determine whether or not some type is supported – and, if so, that method returns a new proxy. The fact that a new proxy instance may be returned does, as such, not add new complications as RMI is already removing the object identity property and several proxy instances may refer to the same remote object.

Java and CORBA With J2SE 1.4, introduced in 2002, support was added for –POA (portable object adapter) –portable interceptors –INS (interoperable naming service) –GIOP 1.2 (general interoperability protocol), –and dynamic any’s. J2SE 1.4 also includes a tool to remotely manage a persistent server and an ORB daemon (ORBD) that enables clients to transparently locate and invoke persistent objects on CORBA-supporting servers.

Interface Definition Language IDL (interface definition language) Used to define an interface according to a certain model (usually an object model) in a programming language-neutral form. Two prominent examples are OMG IDL and COM IDL. OMG IDL is based on a traditional object model, where an object has a single interface that can be composed out of other interfaces using multiple interface inheritance. The methods of an OMG IDL-described interface are called operations. OMG IDL also supports a set of primitive (non-object) types, such as basic types and a selection of constructed types, including structures, arrays, and sequences.

Interface Definition Language COM IDL is based on the COM object model and is a derivative of the older DCE IDL (Distributed Computing Environment ). It does not at all refer to objects or classes, but merely specifies interfaces. A COM object can implement any number of such interfaces. COM IDL supports single interface inheritance as a convenience feature. In both IDLs, polymorphism is achieved by separating implementations from interfaces. In OMG IDL, additional polymorphism is achieved via multiple interface inheritance. In COM IDL, additional polymorphism is achieved via subsets of interface sets implemented by objects.

Interface Definition Language COM and OMG IDL are pure interface definition languages outside the realm of any implementation. Thus, they support only interface inheritance (subtyping). To summarize, there are three cardinal facets of inheritance: –1 subclassing – that is, inheritance of implementation fragments/code, usually called implementation inheritance; –2 subtyping – that is, inheritance of contract fragments/interfaces, usually called interface inheritance; and –3 promise of substitutability.

Interface Definition Language It is surprising that the three facets are usually omitted, or at least not clearly distinguished, when starting heated discussions on the pros and cons. Part of an explanation might be the irrational discussion between “objectionists”and “hybridists.” Alternatively, is it fundamentalists/purists against technocrats/ pragmatists? The former usually refer to the prime directive that object models shall support inheritance (although which of the inheritance facets they insist on is often left open). The latter argue that nothing is impossible and everything may have its place.

Interface Definition Language

System Object Model (SOM) SOM was originally developed independently from CORBA as part of the OS/2 workplace shell. Later, it was made first CORBA 1.2- and then CORBA 2-compliant. In fact, distributed computing is supported by the distributed SOM (DSOM) libraries, which build on SOM. DSOM is considered to be an integral part of SOM. SOM implemented a superset of the CORBA 2 standard and supported metaservices that are still not on the CORBA map. In addition, SOM defined a binary standard.

System Object Model (SOM) Two features of SOM stand out – its support for metaprogramming and support or binary compatibility across binary releases. The SOM metaprogramming model largely follows the Smalltalk example (Goldberg and Robson, 1983), so every class is itself an object and as such an instance of a metaclass. All metaclasses are instances of a single class, Metaclass, which is its own metaclass. SOM goes beyond the reflective capabilities of CORBA as SOM allows classes to be constructed or modified dynamically.

System Object Model (SOM) For example, it is possible to add a new method to an existing class without disturbing any of the existing instances of that class – these existing instances will immediately support the new method. There is at present no other mainstream component platform that supports a similar level of metaprogramming. Runtime code synthesis is supported elsewhere (CLR, Java), but these do not support modifications that affect already existing instances.

System Object Model (SOM) Versioning and binary compatibility are supported by the notion of a release order. For example, adding new methods to a later release does not alter the dispatch indices used by code compiled against an older release. SOM comes with precise rules as to which changes in a release maintain, and which other changes break, binary compatibility with previous releases. Binary compatibility is a very important issue in a component world. It is unthinkable to ask all vendors of dependent components – and the vendors of components dependent on these components, and so on – to recompile and redistribute within any reasonable time.

System Object Model (SOM) SOM guarantees binary compatibility across a large number of base class changes, including refactoring of class hierarchies, as long as the required methods remain available and of compatible signature. As a special case, SOM guarantees that,, then building the next release of a component is guaranteed to preserve binary compatibility with clients compiled against the previous release. This effectively solves the syntactic fragile base class (FBC) problem, but obviously cannot address the semantic FBC problem.