An Object Request Broker (ORB) is the heart of the CORBA architecture and provides the transport mechanism between objects. As shown in Figure 3.6, it provides a layer of abstraction that allows all applications access to all services. Client applications are coded to call and use services on the network as if they were local. Applications can also browse a repository of available object implementations and invoke them dynamically.

Figure 3.6.  A common communications layer allows all applications to access all services.

Client applications and services communicate using Internet Inter-ORB Protocol (IIOP), which runs on top of TCP/IP and is the standard way that CORBA components communicate.

In addition to the ORB and related components, the OMG provides for application objects, common facilities, and common services through its Object Management Architecture (OMA). As shown in Figure 3.7, these higher-level objects and facilities build upon the Object Request Broker foundation and CORBA Services.

Figure 3.7.  The Object Management Architecture (OMA).

Common services provide a way to factor out basic functionality from application components. A few of the better-known services are lifecycle, security, naming, directory, persistence, event management, and transactions.

Enterprise JavaBeans

Enterprise JavaBeans (EJB) is a component model for server-side objects that is part of the Java Enterprise API set. EJBs simplify the task of creating server objects that implement business logic for thin-client applications. With EJBs, developers don’t have to worry about multithreading, state-management, scalability, distributed operations, concurrency, or many other aspects of system design that don’t directly relate to the problem domain.

There are two kinds of EJB: a session bean and an entity bean. Session beans are conversational and retain their state for the duration of the session only. They are not shared between clients. Entity beans are persistent objects, are shared among many clients, and maintain their state indefinitely.

An application server implements an Enterprise JavaBeans container, which provides services to an EJB. As shown in Figure 3.8, those services may include lifecycle support, security, transactions, communications (ORB), resource management, and database access (JDBC).

Figure 3.8.  Enterprise JavaBeans architecture.

A key benefit of the EJB specification is that existing vendors of network servers can become interoperable and host industry-standard components via the EJB container abstraction. Vendors of transaction monitors, database servers, message queuing systems, security management systems, and other network services can expose their native capabilities simply by implementing an EJB container on top of their existing product.

Enterprise JavaBeans will help build the market for both components and containers, because vendors will compete on functionality rather than by locking out competitors with proprietary APIs. Application servers can differentiate themselves by offering different sets of price points and capabilities in areas such as

•  Thread and process management

•  Network access

•  Transaction management

•  Authentication and authorization methods

•  Resource pooling

•  Concurrency management

•  Support for clustered systems

•  Support for high availability

An Architecture for Network Computing

The emergence of vendor-neutral enabling technology is a great boon to the computing industry and will benefit all organizations who rely on information technology. However, the fact that you have an open standard says nothing about the implementation quality. Being compliant with a standard such as CORBA, for example, ensures compatibility and interoperability, but does not address a system’s reliability, scalability, and performance. That’s where Oracle’s products and experience come into play. In this section, you look at Oracle’s implementation of network computing.

Network Computing Architecture

Oracle has been in the business of helping organizations manage their information assets for the last twenty years and has a unique perspective on network computing. Oracle provides a highly reliable and scalable server platform, but it became increasingly frustrated by the limitations of the PC. The complexity and high cost of the PC was limiting the deployment of client software that could access its servers.

Oracle introduced the concept of network computing in 1996 to address its customers’ concerns over administration cost, system reliability, integration, and inexpensive access to data.

Unfortunately, the Network Computer was also introduced at about the same time as network computing, and this has caused quite a large amount of confusion. As you’ll see in a later section, the Network Computer is a particular type of client device. It is not a requirement for network computing; rather it is the icing on the network computing cake.

Oracle’s Network Computing Architecture is a vision, brand, and product road map for enabling network computing. It does not depend on any particular type of computer or client device. It is based on the vendor-neutral, emerging Internet technologies such as Java, CORBA, and Enterprise JavaBeans that were discussed earlier. It is a way of arranging the technologies in such a way as to be useful for driving product development and helping customers make architecture decisions.

From 2-tier to 3-tier Computing

In the traditional 2-tier client/server model, the client (typically a PC) was responsible for both the user interface, as well as most of the application logic. The 2-tier approach forces a lot of complexity and computations onto the user’s desktop and is generally referred to as fat client.