This chapter is from the book
This chapter is from the book
This chapter is from the book
Early Architectures
Earlier approaches to building enterprise solutions essentially focused on functional aspects of the enterprise problem. These approaches tended to directly use the specific implementation environments, such as object orientation, procedure orientation, data or information orientation, message orientation, and so on to solve business problems. This resulted in enterprise solutions that were often tied to features and functions of a particular environment technology. Some of the popular technologies that evolved were Information Management Systems (IMS), Customer Information Control Systems (CICS),2 Common Object Request Brokered Architecture (CORBA), Component Object Model/Distributed Component Object Model (COM/DCOM), and Message Oriented Middleware (MOM).
Enterprise architectures have evolved tremendously since the Mainframe era or the Centralized Model of mainframe architecture. The progression in architectures such as client/server architectures, distributed architecture, or web architectures discussed in Chapter 1, "Introduction," are generic in nature. Specific architectures on mainframe systems, such as IMS, CICS, CORBA, and DCOM, have evolved as environment-specific distributed architectures. You need to analyze some of these technologies and their contribution to the evolution of enterprise architectures.
IMS
IMS is one of the earliest technologies to lay the foundation for more advanced data accessing technologies such as DB2 and Universal Database. IMS was developed by IBM in the late 1960s to manage data for NASA's Apollo Moon Landing project. This technology was later released as the world's first commercially sold Database Management System. IMS technology's data management was based on the earliest data model called the Hierarchical Data model. This premier database and transactional management system was implemented to handle many commercially critical, online operational and on-demand business applications and data that enabled information integration, information management, and scalability.
The IMS technology essentially is composed of two subsystems: a Database Manager called IMS DB and a Transactional Manager called the IMS TM. We explore briefly these two subsystems in the next section.
IMS as Database Manager
The IMS DB is basically a large system Hierarchical Database Management System. When introduced, IMS DB was an enormous success, and many large organizations employed IMS DB for managing the enterprise information. Subsequent research and development efforts by IBM resulted in the revolutionary way of handling the data. The Relational Database Management System (RDBMS) by E. F. Codd in 1971 prompted IBM to introduce a radical product called the DB2. Following the introduction of DB2, IBM intended to replace the Hierarchical Data Management System with relational databases and replace IMS DB with DB2. However, IBM was not entirely successful in replacing IMS because a number of major IMS-based organizations were not interested in replacing the otherwise stable and satisfactorily running IMS-based applications. As a result, IBM continues to develop newer products and packages around the IMS technologies that help those organizations that continue to maintain IMS-based legacy products on their mainframe systems.
IMS as Transactional Manager
The IMS TM is a robust transactional management system that primarily functions on the IBM mainframe systems. This Transaction Manager was initially designed as an interactive system that interacts with an end user, through a combination of 3270 screens and VTAM communication mode to process business transactions. In coordination with IMS DB, IMS TM technology uses a messaging and queuing methodology to implement the transactions in the business processes.
When the user initiates a transaction through a 3270 screen, the IMS Control Program receives a transaction identification number and stores it on a message queue. The Transaction Manager, thereafter, invokes a scheduler on the queued transaction to initiate the business process. The message processing region of the IMS TM then retrieves the transaction from the IMS message queue and processes the same. The processing could involve reading/writing/updating the information on the IMS DB.3 Based on the system design and the architecture of the enterprise application, the IMS TM could respond and return an output message to the user who initiated the transaction on the 3270 terminal.
CICS
CICS from IBM is a transaction server that runs primarily on IBM mainframe systems under operating environments such as z/OS. CICS is now available for other operating environments such as OS/2, AIX, Microsoft Windows, and Linux. The z/OS implementation of CICS is, by far, the most popular and significant implementation of the CICS technologies.
CICS is a transaction processing system designed for both batch and online business transactions. On large IBM mainframe systems, CICS technology supports a large number of transactions in a given time. The CICS technology has enabled IBM to retain a dominant position in the mainframe-oriented enterprise computing. Initially CICS applications were written in COBOL. Presently, CICS applications can be created using a variety of modern programming languages, such as PL/I, C, C++, REXX, and Java. CICS is one of the world's most durable software products on the IBM mainframe system. Supported by a variety of applications and tools, CICS is known for its reliability, security, and performance, particularly on IBM mainframe systems. Thanks to the aggressive marketing by IBM and rich research and development efforts in the United States and the UK, many of the Fortune 500 giants that invested into these systems during the Mainframe era continue to rely on core parts of enterprise applications based on CICS technologies.
The CICS applications programs are basically screens, popularly known as 3270 screens.4 The initiation of a CICS program signals the initiation of a transaction, and the system initiates a transaction identification number. The CICS screens are sent as "maps" or "pages" using a programming language such as COBOL. The end user, on the other end of the system, inputs data that is made available to the CICS program by receiving a map. CICS screens essentially contain textual information. The textual information is presented to the end user in different formats. This includes highlighted text, colored fonts, or even blinking text.
CORBA
CORBA is not that different from the RPC technologies introduced in Chapter 2, "Evolution of IT Architectures." Developed and supported by Object Management Group (OMG), CORBA technology can be considered a generalization of RPC technology and includes several improvements on the data objects and on the data primitives. The purpose of this technology and architecture was to enable the development of distributed applications and services that can interoperably communicate with other disparate applications over the network. The CORBA architecture was essentially developed to bring about a discipline to implement portability and interoperability of applications across different hardware platforms, operating environments, and disparate hardware implementations. CORBA technology uses a binary protocol called Internet Inter-ORB Protocol (IIOP) for communicating with the remote objects.
DCOM
A bit of background is required here. In the mid-1990s Microsoft Corporation introduced a technology popular as the COM.5 This technology enabled the development of software modules called components for integrating applications over the client/server architecture. To build these components, developers must adhere to the COM specification so that the components can operate interoperably within the network. The DCOM technology, introduced sometime in late 1990s, enabled interaction among network-based components to bring in the Distributed Communication Environment (DCE). DCOM technology is essentially built on an object RPC layer, which in turn is on top of DEC RPC to enable the communication among the remote objects. DCOM technology uses a binary protocol, termed Object Remote Procedure Call (ORPC), for distributed communication among remote objects. Technologies such as Object Linking and Embedding (OLE), ActiveX, and Microsoft Transaction Server (MTS) are some of Microsoft's technological advancements built on COM and DCOM technologies.