Network Computingwww.networkcomputing.com

An object-oriented client/server Internet (OCSI) environment provides the infrastructure (i.e., middleware, networks, operating systems, hardware) that supports the modern distributed applications. We have reviewed the key concepts and building blocks of this enabling infrastructure. In summary:

Application engineering/reengineering in OCSI environments is not trivial and requires detailed architectural analysis of various applications as well as platform issues. Examples of the issues are performance trade-offs, security, flexibility, access/integration of legacy systems, and the interoperability and portability of client side software with server side software supplied by different vendors. We will discuss these issues in Parts II and III of this book.

XYZCorp wants to review the IT infrastructure architecture that should serve as the platform for all the services and applications to be provided by XYZCorp. In particular, it should show how the networking services, the middleware components, and other services will support the growing number of Web-based OO applications that will also utilize mobile computing and groupware. This architecture should allow different applications and users at different sites to communicate with each other ("any data from any application anywhere in the company"). The current platforms consist of a variety of devices. The regional offices house minicomputers (mainly UNIX) which are connected to the corporate mainframe (MVS). The regional computers maintain regional inventory, customer information, and prices of items sold in the region. Some regions (e.g., Atlanta and San Francisco) are very UNIX-oriented; other regions have Novell LANs. The corporate headquarters is IBM mainframe-oriented (MVS, DB2, IMS, SNA, Token Ring). PCs are used commonly throughout the organization.

Hints about the Case Study

A high level view of the XYZCorp architecture is shown in Figure 2.18. There are two broad levels of interconnectivity:

Figure 2.18 XYZCorp IT Infrastructure High-Level View

Figure 2.19 shows the middleware components of this architecture. We have shown a few components for the purpose of illustration. The sites where the servers (Web servers, group servers, database servers, etc.) will be housed and the protocols to be used by each of these servers are suggested. The protocol "stack" at each client is also shown.

The purpose of this short tutorial is to give you the basic OO concepts that are of relevance to object-oriented client/server Internet environments. The basic object concepts are comprised of object, message, class, and inheritance.

Objects. Objects are data guarded by a protective layer of code. Figure 2.20 shows the conceptual view of a customer object. The data represent the attributes of the object and the code that surrounds the data represents the methods of the object. Methods are the only way any outsider can interact with the object (you cannot directly view or update customer balance without invoking the "Get-Balance-Due" or "Adjust-Balance" methods). Basically, an object is represented by at least two properties: attributes and methods. Attributes uniquely identify an object and a method shows the object behavior (what it can do or what can be done to it). A method hides the implementation details from the users of an object. A method typically receives a message, performs some operations, and sends the response back. An object essentially is a collection of attributes and the valid methods that manipulate the data elements.

Figure 2.19 XYZCorp IT Middleware Architecture

Figure 2.20 Conceptual View of a Customer Object

Messages. Objects interact with each other by sending messages. These messages invoke particular methods. A message is simply the name of an object followed by the name of an appropriate method. In addition, the message may contain a set of parameters that the invoked method needs. Figure 2.21 illustrates two messages sent to the customer object, one with parameters the other without. Each method of an object knows the list of messages to which it can respond and how it will respond to each. The object that receives the message is responsible for providing the code that is needed for the invoked object. The receiver should also advertise its methods and the parameters to be invoked for each method so that the outside world can take full advantage of objects.

Figure 2.21 Messages to Customer Object

Classes. A class is a template that represents the properties that are common among similar objects. The basic purpose of class is to define a particular type of object. For example, the class employee can be used to represent the common properties of all company employees. The common properties include attributes such as name, address, employee id, grade, pay scale, et cetera and methods such as view, update, terminate, and the like. So, if in a programming system you have identified object types such as employees, customers, and products, then you will define three classes to correspond to these object types. Each class will define the properties of each object type. The objects belonging to a particular class are known as instances of that class. For example, the objects Joe Smith, Harry Kline, and Pat Hemsath are instances of the class employee. Once you have created a class, you can create any number of instances of each class (object-oriented programming languages provide statements to create instances). The instances contain the information that makes them unique. For example, the object instance of Joe Smith will have information unique to Joe Smith.

Inheritance. Classes can be defined independently of each other. For example, the employee, customer, and product classes can be defined independently of each other. However, classes can inherit common properties from other classes. The properties to be inherited can be attributes as well as methods. A class hierarchy can be constructed where lower level classes (subclasses) inherit the properties from higher level classes (superclass). Figure 2.22 illustrates a class hierarchy. We can set up a class hierarchy for our employee class with subclasses such as managers, technical support, administrative support, consultants, visiting residents, and part-time staff.

The basic object concepts can be used to represent powerful programming systems. An object-based system is defined as follows [Chin 1991, Taylor 1994]:

For example, an object-based programming language supports objects and classes as a language feature but does not support the concept of inheritance. ADA and Modula-2 are examples. Object-based concepts are quite general and can be found in application programs that existed before objects became fashionable.

Our interest is in object-oriented systems that go beyond object-based systems. The following widely accepted definition of object orientation is given by [Wegner 1987]:

OOPLs support classes, objects, methods, messages, and inheritance (note that methods and messages are implicit in this definition). A more generalized definition, more suitable for distributed systems, is given by [Nicol 1993]:

Figure 2.22 Class Hierarchies (Source: [Umar 1993])

Let us review the three ingredients of this definition of OO. As we will see, this definition is quite similar to Wegner’s definition, albeit more general.

Abstraction. Abstraction focuses on the outside view of an object, that is, how it will appear to the outside world. The following definition of abstraction has been given by Booch [1994, page 39]:

Thus abstraction allows us to group associated entities according to common properties, for example, the set of instances belonging to a class. Abstraction represents the object properties without attention to implementation details. Methods as well as messages support abstraction by focusing on the outside view of an object.

Encapsulation (Information Hiding). Encapsulation, also known as information hiding, prevents the clients from seeing the internals of an object. Encapsulation complements abstraction–encapsulation focuses on hiding the internals while abstraction focuses on presenting an external view. Encapsulation has been defined by Booch [1994, page 46] as following:

Encapsulation as well as abstraction are important to the design of an OO system, especially when the objects can be at different sites. In particular, each object must have two parts: an interface and an implementation. The interface of an object only captures its external view (i.e., the object name, the method to be invoked, the parameters to be passed). The implementation of an object contains the mechanisms that achieve the desired behavior (i.e., the code for each method). The interface is also known as the public part of an object and the implementation is known as the private part of an object.

Polymorphism. Polymorphism is a Greek term meaning "many forms." Polymorphism allows you to hide alternative procedures behind a common interface. Basically, you can use the same method name in more than one class. A popular form of polymorphism is inclusion polymorphism in which operations on a given type are also applicable to its subtype (for example, a printer will start all types of printers). Inclusion polymorphism is often implemented via an inheritance mechanism. Polymorphism is defined as the quality or state of being able to assume different forms [Taylor 1994]. Polymorphism can be displayed in messages and/or objects. An example is send the same message, "delete," to different objects that respond to it differently. For example, some objects may completely erase the information while the others may just flag it for erasure at a later stage. Polymorphism is considered to be one of the defining characteristics of object-oriented technology. It distinguishes object-oriented programming languages from more traditional programming. By allowing the same method name in different classes, you can use the same message (e.g., delete, print, draw) to get different results by simply pointing to a different class at run time. Thus polymorphism takes advantage of inheritance and "dynamic binding" (i.e., deciding at run time what object you want to communicate with).

Literature on IT infrastructure is growing steadily. This chapter has quickly scanned the topics that are discussed in great detail in Umar [1997]. Additional information can be found in the books by Berson [1993], Khanna [1993], Orfali [1994], Stevens [1990], Umar [1993], and Vaskevitz [1993]. State-of-the-market and state-of-the-practice articles on IT infrastructure appear regularly in trade journals such as Client/Server Today, Datamation, Database Programming and Design, and Data Communications. Analysis of IT infrastructure directions can be found in the reports published by the Gartner Group, Forrester Research, and the Yankee Group.