Clearpath Forward® As Open Systems
Total Page:16
File Type:pdf, Size:1020Kb
ClearPath Forward® as Open Systems By: Peter Bye White Paper The IT industry’s understanding of what it means to be an open system has evolved over the years. The original concept focused on certain operating systems and hardware: for example, there should be more than one source of hardware. Today, openness is concerned with the interfaces a system supports. This understanding suggests that openness is not a binary attribute; systems are not simply open or closed but are somewhere on a spectrum of openness. This paper discusses the characteristics of open systems and establishes a framework for analysing the openness of any system. It then considers ClearPath Forward® systems using the framework. The results show that ClearPath Forward systems are towards the open end of the openness spectrum. They support the major interfaces, especially for co-operating with other systems in distributed architectures, for example within a service architecture implementation. The paper was last revised in 2014 with the title ‘ClearPath® as an Open System’. The 2018 revision reflects product name changes and the fact that all ClearPath Forward systems now use Intel hardware, with firmware providing the system architecture rather than hardware. ClearPath Forward Libra (ClearPath MCP-based) and Dorado (ClearPath OS 2200-based) systems use Unisys supplied Intel-based hardware. The ClearPath Software Series may run in hardware of the client’s choice. 2 Table of Contents Summary 4 Introduction 5 ClearPath Forward Systems: Architectural Positioning 5 What is an Open System? 6 Perspectives on Openness – An Analytical Framework 8 Evaluating ClearPath Forward Open Attributes 9 Perspective 1: Interfaces 9 Perspective 2: Application Development 17 Perspective 3: Systems Management and Operations 18 ClearPath System Mission-Critical Attributes 19 Sources of Information 20 Appendix A: ClearPath Forward Architecture 21 Appendix B: Glossary 23 About the Author 25 3 Summary Definitions of open systems have changed over the years. An early view was that an open system was one where the hardware was obtainable from more than one source. More recent definitions of an open system from vendor-independent bodies such as The Open Group and the Carnegie Mellon Software Engineering Institute (SEI) centre on the internal and external interfaces it exposes, not on the hardware or operating system platform. ‘Open’ in this context means support for widely-used interfaces, sometimes called ‘industry-standard’. The reasons behind this focus include: • Current application environments, especially Java, shield the underlying platform from applications, allowing a very high degree of portability. The platform is not relevant to openness. • Systems are increasingly collaborating with others in distributed applications, both intra- and inter-organisation. Inter-system communication across independent groups or organisations requires industry-standard interfaces that make no assumptions about the technologies used to develop and deploy the various systems. Web Services is an example of such a technology. Based on these definitions, it is clear that openness encompasses a spectrum of open interfaces; a system is not open or closed but somewhere on a spectrum-between the two. At one end of the spectrum, there are few open interfaces; at the other end, there are many. Adding more industry-standard interfaces makes a system more open. Where do ClearPath Forward systems lie on the openness spectrum? They are open in that they lie at the ‘open end’ of the spectrum. They support an extensive range of standard and de facto standard interfaces, including: • Implementations of industry-standard application environments, including Java, Java EE and Open Group DTP. Support for Java allows easy importing of software written in Java. These environments are integrated with the native application servers COMS and TIP/HVTIP, and can access native databases and other data stores. • Support for industry-standard communications protocols and FIPS-certified encryption algorithms. • Provision of all the major industry-standard middleware technologies, enabling a wide range of collaboration options, including participation in service architecture implementations. The range of middleware supported is particularly rich. • Support for distributed transactions across multiple systems of different types. However, openness is not the only desirable system attribute. ClearPath Forward systems are typically used in mission-critical environments such as high volume transaction processing. Attributes such as reliability, efficiency, responsiveness to rapidly changing conditions and security are essential. ClearPath systems are particularly strong in these attributes, largely due to the way they are delivered. All the necessary components, from operating system to application environments, and the machine in which they run, are optimised for performance, integrated and tested before release. This avoids the need for complex and expensive integration by users, which is required if the products come from a number of different sources, as is typical with many systems regarded as open. The combination of mission-critical and open attributes results in systems which are powerful and secure transaction processing platforms, and are able to participate in distributed environments. These characteristics differentiate ClearPath Forward systems from other platforms commonly viewed as open. A note on terminology: in the context in which it will be used throughout this paper, the word ‘machine’ is taken to include hardware and/or firmware. The reason is that all the newest ClearPath Forward systems run on Intel hardware. The required system architecture – instruction set, I/O connectivity and so on – is provided by firmware. ForClearPath Forward Libra (ClearPath MCP-based) and ClearPath Forward Dorado (ClearPath OS 2200-based), Unisys supplies the Intel-based hardware and the firmware. For the ClearPath Software Series, the client chooses the hardware; Unisys supplies the firmware and provides configuration guidance. This paper uses the term ‘machine’ to cover both of these options. 4 Introduction This paper aims to substantiate the view that ClearPath Forward systems are open, and well-suited to hosting mission-critical applications. It examines the open characteristics in the light of the widely-accepted standard and de facto standard interfaces that determine openness. And it shows how ClearPath mission-critical attributes support the systems’ primary role in high performance, secure environments, with extensive transaction processing. The remainder of the paper is divided into the following sections: • The first section sketches out the hybrid architecture required for today’s and future IT environments, showing where ClearPath Forward systems fit. • The next section reviews the definitions of open systems, in the context of what is required to fit into the architecture outlined in the previous section. • Using the definitions as a starting point, a framework for analysing the open attributes of a system is presented. • The paper then uses the framework to analyse the open attributes of ClearPath. • The following section discusses the mission-critical attributes of ClearPath systems. • The paper concludes with some pointers to sources of additional information. A brief description of ClearPath Forward architecture and a glossary of technical terms mentioned in the paper are appended. ClearPath Forward Systems: Architectural Positioning Figure 1 is a schematic of an architecture able to respond to the demands placed on a typical organisation, referred to as Organisation X. The environment divides into internal and external domains. The internal domain is below the horizontal red line in the figure. It contains one or more internally-managed data centres housing the critical applications and databases – the systems of record – and other supporting applications, for example for test and development. What is critical will depend on X’s business. As examples, a bank would include systems for account management and customer information, and a government income taxation service would include tax payer and account status systems. The external domain is connected through one or more networks: dedicated private, industry networks such as shared ATM and interbank networks, and the internet. Which types and how many such networks will depend on the nature of X’s business. The external domain is divided into three parts: consumers of X’s services; providers of services to X, including cloud services; and devices connected to the Internet of Things (IoT). Consider each in turn. Service consumers include individuals using mobile and other devices, as well as employees of X, providing a call centre service for instance. Consumers also include other systems to which individual users may connect, for example price comparison applications. The services provided by X may be delivered entirely by internal applications but are likely to include external service providers: the total service is a collaboration. Service providers include shared services, for example credit reference, payment and transportation systems. X may choose to keep some of its less critical applications externally, in cloud services. X could also use cloud facilities as overflow capacity in the event of excessive loads on its internal resources. The IoT represents a rapidly growing source of data from a wide variety of entities. Traffic may flow in two directions: