[MUSIC] Programming paradigms are continually changing in order to address our growing needs and to improve on how systems are built. Similarly, systems and their standards need to evolve as new programing paradigms are introduced. Developers may need to create new architectural designs in order to take full advantage of new approaches. With the widespread adoption of object oriented programming, new systems were written to take advantage of object oriented design principles, such as class inheritance, generalization, abstraction, and encapsulation. However, it is expensive to design and create new systems from scratch. While older systems can't take advantage of the features in object oriented languages, their design is still applicable and relevant. Instead of designing a new architecture around a different programming paradigm, we can update existing architectures using the new paradigms. Remote procedure calls have evolved in this manner. Instead of being relegated to be a legacy system, they have been used as the basis for middleware architecture, based on object brokers. Object brokers combined the distributed computing aspects of remote procedure calls with object oriented design principles. By including object oriented programming, object brokers simplify and allow distributed systems to use an object oriented approach. In this lesson, we will look at the architecture, benefits, and criticisms of object brokers. But first, let's take a brief look at the history of object brokers. In the late 1970s, the concepts of object oriented programming were introduced to the world. It simplified data abstraction by allowing programmers to define an abstract data type using a class. The data encapsulated by a class, called the attributes, are used to define its properties. The procedures that a class is able to perform became known as methods, which describe its behaviors. All non-static classes are constructed into objects through a process called instantiation. This allows programs to dynamically create new instances of objects at runtime. In addition, a class could have multiple unique instances existing at the same time. Classes and objects introduce two concepts that change the way methods are identified, inheritance and polymorphism. In previous programming paradigms, the signature of a procedure in a program was unique. This meant that a globally accessible procedure with a specific signature has only a single implementation. In object oriented programming, inheritance and polymorphism allows different classes to have different implementations of the same method signature. This causes an issue for middleware, where services must be provided for each object. The middleware must be able to direct a remote call to the correct server, with inheritance and polymorphism taken into account. Thus, object brokers are a natural evolution from remote procedure calls. This extension began in the 1990s in order to address the issues in how middleware should handle object oriented programming. The most common object broker architecture is called Common Object Request Broker Architecture, also known as CORBA. Despite having the word architecture in its name, CORBA is more closely related to a set of standards. Devised by the Object Management Group, or OMG, CORBA is meant to provide an outline of what should be included in object brokers. The standard is not a how-to guide for implementation. Since there are numerous object oriented languages, the primary goal of CORBA is to create a specification that allows object brokers to be independent of the programming languages used to implement clients and servers. In addition, client-side and server-side operating systems are often different because the quality requirements are different. CORBA specifies that object brokers should be able to function independent of the operating system. The intent is that if a system requires middleware to handled distributed computing, developers do not need to be restricted to the language and OS requirements of the middleware. Similar to procedures in an architecture based on RPC, objects can be distributed amongst a network of computers, allowing them to reside in different physical address spaces. Or, they can be distributed throughout different processes on the same computer, which lets objects exist in different virtual address spaces. Object brokers and the CORBA standard are important in the evolution of middleware and distributed computing. It sets the foundation for Microsoft's .NET framework and the Java 2 Enterprise Edition framework offered by various vendors. CORBA consists of three main components. The first component is called the object request broker. It provides object interoperability to the client and the server. An object must declare its interfaces before it can be accessed by a client or server through the broker. The broker is also responsible for marshalling and unmarshalling all the method calls that it receives. This allows you to modify the client or server without having these changes affect the other. The second component is called CORBA services. There are services provided by the middleware to the objects being used by the client and server. Services provided vary, and may include functions needed for persistence to functions related to object security. All CORBA services are accessible through the CORBA standardized API. The last component is called CORBA facilities. While CORBA services provide functionality at an object level, CORBA facilities provide services at an application level. These are usually high-level functions, such as document management. So how do these components work together to provide systems with a means for object oriented distributed computing? Remember that object brokers are an extension of the RPC architecture. Therefore, it follows the same architectural design of using an interface definition language, or IDL, for generating the stubs used to facilitate communications within the system. Since we have explored the IDL and stubs in the RPC lesson, in detail, we will only look at the enhancements that object brokers have made to them. The IDL in CORBA is very similar to the IDL in an RPC-based system. The enhancement that CORBA makes is that the IDL is capable of supporting inheritance and polymorphism. All object interfaces must be declared in the interface definition language in order for them to be presented to the client. In order for CORBA middleware to allow clients and servers to be developed in different programming languages, the CORBA IDL has a standardized mapping to multiple object oriented languages. Standardization also allows the IDL to be portable across brokers by different vendors. Just as in the RPC architecture, the CORBA IDL compiler is responsible for constructing the client stub and server. In terms of functionality, they are similar to their RPC counterparts. Since we are dealing with objects, the stub and skeleton need to be built upon in order to be able to handle objects. The client stub acts as a proxy object. It essentially hides all the objects that are distributed and being served by the brokers. Since the objects are hidden and the stub is linked to the client application, all method calls to the objects being served appear as if they are local invocations. In addition, since the client accesses the remote methods through the stub, the stub must also contain the method declarations of all the objects distributed throughout the brokers. The server skeleton hides the object distribution from the server application. Since the remote objects are making function calls to the server, the skeleton will act as a proxy object, and make it appear as if the calls are coming from a local object. This architectural design means that your client needs to know your server's IDL in order for the two to communicate with each other. Without this knowledge, your client won't be able to access the methods that are being served by the object broker. Interoperability can only be achieved when the client binds to a least one broker. Without binding, the client can't access the behaviors of the objects. The easiest method of binding is to do it statically. Static binding occurs when when the client stub is created. The service that is used for static binding to a broker is handled by the IDL. When the IDL compiler generates a stub, it will be statically bound to the broker that the IDL compiler belongs to. Dynamic binding is also specified in CORBA. It offers advantages over static binding by allowing clients to dynamically search for new objects, retrieve their interfaces, and instantiate the discovered objects. In dynamic binding, the ideal compiler does not need to generate a stub, but requires two additional components instead. The first component is called the interface repository, which is used to store the IDL definitions for all the objects being served by a broker. The second component is the dynamic invocation interface. This component provides all the necessary operations that a client needs for browsing in the interface repository, and dynamically constructing methods based on what the client discovers. Object references are provided by two services in the dynamic invocation interface component. The naming service allows the client to retrieve objects using the "name" of the interface that the client needs. The trading service will let the client search for objects based on object attributes. This provides the client with two ways in which they can search for and discover new methods. Unfortunately, building the dynamic invocation interface is semantically difficult. This means that a lot of work needs to go into building the logic for the component. It is the searching semantic that is difficult to implement. The client needs to understand the meaning of each service property in order to properly search the repository for services. Therefore, a naming convention needs to be implemented so that both the client and the dynamic invocation interface can understand each other. For example, the word get has several synonyms, such as fetch, retrieve, and obtain. Both the client and the dynamic invocation would need to understand that these words could all mean the same thing. Additionally, the client needs to know how to interact with the services that are discovered. Otherwise, the client will have a hard time determining what the behavior of a newly discovered service is, what the parameters mean, or in what order services need to be invoked so that the desired effect is achieved. The cost associated with implementing the semantic rules for the dynamic invocation interface generally outweigh the benefits. This is especially true in large and robust object brokers because there are more semantic ties to discover and implement. Besides being able to handle distributed computing in an object oriented paradigm, there are other benefits of using CORBA for a middleware system. The broker keeps track of and maintains both the references made to the objects and the actual address of the objects, while a client only needs to make references to the objects. This means that if the physical or virtual address of an object changes in the broker, the client will still have access to it. Objects are essentially independent of the physical and virtual address because they can move around, but still be referenced. Being technologically independent of programming languages and operating systems allow development of clients and servers to occur without any restrictions. CORBA also provides a variety of options in regards to data. For instance, data can be strongly or dynamically typed. Data can also be marshalled into binary form, or compressed in order to reduce the size of the data that is sent. CORBA also provides standards for optimization by allowing developers to manage threads and network connectivity settings. Like any other architectural standard, CORBA is not without its faults. Most of the problems are not due to the CORBA standards themselves, but are a result of poor implementation of the CORBA standards. Any system that doesn't implement the CORBA standards correctly will suffer. The issues will usually occur in the broker of the system, which can lead to an overly complex and incoherent API, difficult-to-use object brokers, and overall poor performance. Why does poor implementation happen? There can be several reasons, such as inexperience of the development team. Or, the need to reduce cost, since it is expensive to implement a system that meets the CORBA standards. While a strength of CORBA systems is that objects are not restricted to a physical or virtual address, the design also causes location transparency. If objects that interact exist in the same physical or virtual address space, they still treat method calls as if they were in different spaces. This means that method calls that should be local are done in a remote manner. As a result, method calls are always made in the most complex way possible, regardless of where objects are located. Although object brokers are largely considered legacy SOA systems, it is important to understand its evolution, and why it was needed. Service oriented architectures continue to evolve alongside of technology. While object brokers were a popular means of implementing SOA, web services and technologies are the next evolutionary step in response to the dominance of the Internet.
