Identify Technologies outside of CORBA that provide Similar Functionality

CORBA is not the only technology available that has been designed to provide a foundation for building distributed applications. Regardless of whether these technologies are viewed as competing directly with CORBA, there is the all-important concept of interoperability.
Many organizations have already built distributed systems using other technologies and choosing CORBA as a solution often means that each technology should provide some type of interoperability options to developers and administrators. In this lesson we'll look at Microsoft's Component Object Model (COM) technologies and Sun/Javasoft's Remote Method Invocation (RMI), and also briefly looks at some bridging technologies that have been introduced.

• Component Object Model (COM)
  Many people assume that Microsoft and the OMG are at war, which is not the case. Microsoft is a member of the OMG and the OMG has invested effort to ensure COM/CORBA interoperability. Microsoft originally asked the OMG to change the CORBA specification to fit COM. When that did not meet with success, the focus moved to interoperability. Chapter sixteen of the CORBA specification is devoted to specifying the COM/CORBA mapping. Chapter seventeen covers mapping between CORBA and OLE automation. Microsoft has licensed COM to IONA, allowing a major vendor to create CORBA/COM ORB interoperability. Many ORB vendors also offer CORBA/COM bridging products that enable interoperability.
• DCOM
  The Distributed Component Object Model (DCOM) Remote Protocol is a protocol for exposing application objects by way of remote procedure calls (RPCs). The protocol consists of a set of extensions layered on Microsoft Remote Procedure Call Protocol Extensions as specified in [MS-RPCE]. The DCOM Remote Protocol is also referred to as Object RPC or ORPC. The DCOM Remote Protocol extends the Component Object Model (COM) over a network by providing facilities for creating and activating objects, and for managing object references, object lifetimes, and object interface queries. The DCOM Remote Protocol is built on top of Remote Procedure Call Protocol Extensions, as specified in [MS-RPCE], and relies on its authentication, authorization, and message integrity capabilities. The following diagram shows the layering of the protocol stack.
• Remote Method Invocation (RMI)
  Javasoft's RMI API was originally perceived as a threat to CORBA, but Javasoft has committed to having RMI use IIOP as its underlying protocol, which will make RMI and CORBA interoperable. Sun's Enterprise JavaBeans effort is designed to work with both CORBA and COM, which represents yet another avenue for CORBA/COM interoperability.

When considering the borders surrounding different technology areas that provide similar functionality, interoperability really is a two-way street. However, the fact that the ORB vendors and third-party vendors are talking realistically about providing interoperability is a good sign. Make sure your vendors know that interoperability is important to you and request that they provide open solutions. If the market demands open solutions, they will become commonplace.

The ability to integrate the enterprise's legacy IT assets is perhaps the most overriding consideration for middleware adoption. Millions of lines of code and megabytes of data represent the business intelligence that drives the present and future survival of the enterprise. For the majority of organizations that are considering middleware, wholesale replacement of all IT assets at once is simply not possible. The need to maximize previous investments by extending the lifetime of legacy IT assets is critical. Controlling the pace of transition in a way that minimizes impact on the operational environment is also a paramount consideration.
With the wide spread utilization of object technology, it has become more and more important to employ the object oriented paradigm in distributed environments as well. This raises several inherent issues, such as references spanning address spaces, the need to bridge heterogeneous architectures, etc. It is the main goal of this paper to provide an architectural analysis of current software platforms in this area. One of the obstacles to overcome in order to achieve this aim is the fact that the available descriptions of these platforms speak different languages. Thus to target the issue, we have decided to employ design patterns as a common denominator which will help us provide an unified view on the platforms analyzed. We focus on the following key distributed object platforms: CORBA, Java RMI, and COM/DCOM. The first one, CORBA, is specified by OMG [12], which is the largest consortium in the software industry. CORBA has undergone an evolution ranging from CORBA 1.0 (1991) and CORBA 2.0 (1995) to CORBA 3.0, which is soon to be released. The Java environment, designed by Sun Microsystems, has probably experienced the greatest evolution recently. From the broad spectrum of the Java platform segments, we will focus on Java RMI [22], which targets working with distributed objects. The last platform analyzed is the Microsoft Component Object Model (COM). This platform has also been evolving gradually along the milestones OLE, COM, DCOM, and COM + .
The general principles of working with distributed objects and the division of the section reflects our approach to the architectural analysis - basic principles, basic patterns, provision and employment of a service, and inherent issues. The analyses of CORBA (Sect. 3), Java RMI (Sect. 4), and COM/DCOM A thorough evaluation of each platform could not be provided since all of these areas have become very broad and each of them requires individual analysis.

Some of the third-party vendors for Corba that existed during the dot.com period are no longer in existence. The OMG is defining the standard for CORBA, which in turn is implemented by companies, also known as ORB vendors. Since the OMG is a vendor consortium that is open to everyone, you can participate in the process continue of what is defined by the OMG. A specification adopted by the OMG must be implemented by the submitters.

• BEA Tuxedo CORBA Environment
  The CORBA environment in the BEA Tuxedo product is based on the CORBA standard as a programming model for developing enterprise applications with high performance, scalability, and reliability. BEA Tuxedo CORBA extends the Object Request Broker (ORB) model with online transaction processing (OLTP) functions. The BEA Tuxedo CORBA deployment infrastructure delivers secure, transactional, distributed applications in a managed environment. CORBA objects built with the BEA Tuxedo product are accessible from Web-based applications that communicate using the CORBA Object Management Group (OMG) Internet Inter-ORB Protocol (IIOP). IIOP is the standard protocol for communications running on the Internet or on an intranet within an enterprise. BEA Tuxedo CORBA has a native implementation of IIOP, ensuring high-performance, interoperable, distributed-object applications for the Internet, intranets, and enterprise computing environments. You can build integrated enterprise applications using multiple programming models. CORBA and Application-to- Transaction-Monitor-Interface (ATMI) applications can be developed with fully integrated transaction management, security, administration, and reliability capabilities.
• The BEA Tuxedo CORBA Environment has undergone significant changes over the years. Notably, the BEA Tuxedo CORBA Java client and its associated ORB were deprecated in Tuxedo 8.1 and are no longer supported. However, the C++ components of the CORBA environment continued to be supported in subsequent releases. As of January 17, 2025, there is no publicly available information confirming the complete sunsetting of the BEA Tuxedo CORBA Environment. For the most accurate and up-to-date details regarding the support status and lifecycle of specific components within the BEA Tuxedo CORBA Environment, it is advisable to consult Oracle's official documentation or contact Oracle Support directly.

The interoperability technology incorporated into BEA Tuxedo CORBA provides for scalable connectivity between the CORBA and WebLogic Server environments.