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: from the IoT as status and other information and to the IoT in the form of control commands.
All ClearPath Forward systems now use Intel hardware, with Unisys firmware providing the system architecture – the instruction set, I/O connectivity and so on. ClearPath Forward Libra and Dorado systems use Unisys Intel-based hardware and firmware. The systems would typically be installed in an organisation’s own datacentres. They are shown in figure 1 with red shading. The Unisys-supplied hardware platforms for ClearPath Libra and Dorado systems include options for high availability by duplicating some of the Intel servers used within the systems, making them ideally suited to be systems of record.
5 Service consumers Cloud and other Things service providers (some may also be consumers) X’s applications in the cloud . Commodity . Less critical . Overflow capacity Other applications
o External o o o o o o o
Network(s): private, industry (e.g. SITA, SWIFT), Internet
o o o o Systems of record: o o o o o o o o ClearPath Forward Mission-critical applications o o o o o o ……… o o Libra and/or Dorado with demanding service o o ………….. o o levels o o o o ClearPath Internal o o o o Software Series Organisation X’s own data centre(s)
Figure 1: Hybrid architecture illustrating how ClearPath systems may be deployed
The ClearPath Software Series may run in any suitable Intel hardware. They would be deployed internally as shown in figure 1 with green shading. The ClearPath Software series also represents a first step towards cloud deployment as it removes the requirement for Unisys-supplied hardware. (Appendix A provides a brief architectural description of ClearPath Forward systems.) What is an Open System? 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. The rise of distributed intra- and inter-organisational environments, has shifted the definition of openness to interfaces: an open system is one well-suited to collaborate in distributed environments – see figure 1. Three questions arise from the above. 1. What are the interfaces referred to in the definitions? 2. Why might they be considered to be open? 3. Who defines them? The interfaces are both internal, that is within a system, and external, for communicating with other systems. Figure 2 shows internal interfaces between components, for example those labelled C (n) and C (n-1), and external interfaces to other components. Suppose for instance that C (n) is an application component accessing a database. The interface it uses to access the database manager would be something like SQL (Structured Query Language). C (n-1) would be the database manager, which would then have an interface to a file manager. The file manager would interface to a disk handler for the physical I/O, which would access the storage subsystem.
6 External interfaces
C (n) Intersystem A B protocols Internal interfaces C (n-1) Intersystem protocols
C (1)
External connections
Figure 2: Internal and external interfaces between components
Figure 2 also shows external interfaces to peer components in other systems, which would involve a protocol for communicating between the components. Architectures such as the Open Systems Interconnect model from the International Organization for Standardization (the ‘ISO-OSI’ model) were defined on a layered principle, where each layer exposes services accessed by the layer above through an interface. Each layer communicates with its peer layer in another system using protocols. Figure 2 shows a connection between the two (n) layers with end points labelled A and B.
Why would an interface be considered as open? The essential requirement is that the definition or specification is in the public domain in some form and not hidden. Implementations may therefore be available on a variety of platforms, both machine and operating system, and additional implementations may be made in platforms not already included.
Who defines the interfaces that are considered to be open? Perhaps the most genuinely open are standards which are defined by vendor-neutral groups. So standards such as TCP/IP are open, because the Internet Engineering Task Force (IETF), which defines TCP/IP, is vendor-neutral. Web Services standards such as SOAP, defined by groups such as the W3C, are similarly open. The International Organization for Standardization (ISO) and International Telecommunications Union (ITU) are further sources of this class of open standards.
A second class of interface contains de facto standards, which are those that are not defined by a vendor-neutral group but have been widely implemented and accepted. One of the most popular de facto middleware standards is IBM MQ, which is defined by IBM but available on many platforms, including ClearPath Forward systems. Java standards arede facto standards, because although they originate from Sun (now Oracle), they are widely implemented.
A third source is exemplified by RESTful APIs, which are supplanting SOAP. They can be best described as a ‘community’ definition of an architectural style, which is becoming the building block of Microservices and cloud native applications.
Implementations of standards can take two broad forms. First, the specification may be implemented by anyone and released as a product of some kind. In some cases, the implementation may have to undergo a validation or certification process if it is to claim conformance to the specification 1. Examples needing validation include telecommunications software to connect to public networks, and implementations of Java specifications. The second implementation approach is that the specification is implemented by a single vendor, which makes it available as a portable product, either open source or with a licence fee. IBM MQ is an example of this type of implementation, in this case with a licence fee.
1. Certification can be costly and time consuming, so some implementations are released without going through the process. The implementation may in fact be complete but cannot claim conformance without undergoing certification.
7 One final observation: the use of terms such as ‘proprietary’ and ‘single source’ can complicate discussions about openness. Proprietary is frequently interpreted as bad and therefore to be avoided. But most products are proprietary in the sense that they come from specific suppliers. What matters is that they have open attributes. Two Java EE, application servers, for instance, have identical open standard attributes. They can be differentiated on price, performance, and on features that are not standardised and depend on specific implementations, such as resilience. Perspectives on Openness – An Analytical Framework One point that emerges from the above discussion is that systems should not be considered as either open or not open; rather, openness encompasses a spectrum of open attributes, in particular interfaces. At one end of the spectrum, there are few open interfaces; at the other end, there are many. Evaluating any particular system or class of systems therefore requires finding out the open attributes it possesses and thus discovering where it sits in the spectrum. The richer the set of open attributes the system possesses the more open it is.
Evaluating the openness of any particular system requires some form of analytical framework identifying the particular attributes or attribute types to be considered. The approach used in this paper is to view a system from three perspectives, which together encompass the important open attributes. They are:
1. The interfaces available, which cover a wide spectrum of options, including simple message exchange, direct data access and data sharing, and distributed transactions. 2. The application development tools and processes that can be used. This perspective goes beyond the definitions of ‘open’ established above because development tools and processes are not standardised. However, users of systems considered as open tend to expect particular development approaches and the availability of popular tools. 3. Systems management: can the system be managed using the technologies and products able to manage other common systems, or at least collaborate with them? Figure 3 shows the key components.
Widely accepted systems management technologies
Storage subsystems
Machine(s) Operating system File and DBMS management
Application Servers Applications
Integration middleware Intersystem protocols Communications management
Internal and external devices and systems
Figure 3: Components and interfaces used in the analytical framework
8 Evaluating ClearPath Forward Open Attributes Unisys has supported the development of freely available, open standards over many years by participating in their development on standards committees; it contributed significantly to the specification of XML for instance. It has backed up this commitment by implementing the resulting standards in the ClearPath Forward systems and their predecessors. The following sections evaluate the openness of current ClearPath Forward systems, using the analytical framework developed above. Both system families generally implement the same technologies and standards although the implementation approach may vary. Any significant differences between the system families are noted. There may also be implementation differences between ClearPath Forward Libra and Dorado systems, where Unisys supplies the hardware, and ClearPath Software Series, for which the client chooses the hardware. Appendix A contains a brief description of the system architectures. Perspective 1: Interfaces The interfaces discussed are divided into three groups: application environments, data access and sharing, and loosely-coupled. A note on security completes the section. Application Environments Internal Components and interfaces Figure 4 shows the key internal components and interfaces, which are discussed in the following paragraphs. Both MCP and OS 2200 systems also support an extensive set of middleware products to integrate with other technologies in a variety of ways. As shown in figure 4, integration middleware may run under the native operating systems and/or externally, depending on the product.
Storage subsystems
ClearPath Forward System MCP or OS 2200 File and DBMS (DMS II, RDMS, DMS, BIS…)
Application Servers COMS, TIP/HVTIP, Open DTP Applications
Integration Middleware
Communications management
Integration middleware may run under MCP or OS 2200 or externally, depending on the product.
Figure 4: Internal components and interfaces Both ClearPath families support native application environments conforming to Unisys’ own definitions, running the Unisys operating systems. They also provide an industry-standard environment, which is implemented by other organisations on a variety of platforms. Consider each class of environment in turn.
9 Native application environments support both batch and transactional applications. The transaction processing environments (COMS with MCP and TIP/HVTIP with OS 2200) are integrated with the operating system and other software, providing an extensive set of features, especially for recovery and security. Applications may be written in a variety of industry-standard languages such as COBOL and C. Support of standard file and database APIs, as explained later, facilitates the import of applications and software written elsewhere.
Both system types provide a native Web server, supporting the development of Web-based applications. A variety of features is available for Web-enabling existing applications originally developed for use with terminals such as the T27 (MCP) and UTS (OS 2200).
The industry-standard application environment Open Group DTP 2 is supported under the ClearPath operating systems. The Open Group DTP model defines an environment for transaction processing, which, as its name suggests, includes transactions distributed across multiple systems implementing the same model. The implementations on ClearPath systems, called Open DTP, are extensions to the native integrated transaction processing environments (COMS and TIP/HVTIP). They include support of two-phase commit to maintain consistency of databases and queues (in conjunction with IBM MQ) within a single system, and across multiple systems. The implementation is widely used by ClearPath customers, especially in the OS 2200 base. Files, Databases and Storage ClearPath system databases provide widely accepted interfaces from programs running on the platform. RDMS on OS 2200 and the new Relational Database Server for ClearPath MCP (MCPSQL) provide native SQL access to relational databases. MCPSQL also provides SQL access to DMS II databases on MCP.
ClearPath systems use industry-standard storage subsystems, for example those from Dell EMC, and access technologies such as Storage Area Networks (SANs). Communications Communications standards from the Internet Protocol Suite (aka TCP/IP), as defined by the IETF, are now ubiquitous in the industry. In common with other vendors, Unisys has progressively used TCP/IP to phase out a long history of communications implementations, including:
• Its own communications standards, ranging from terminal and workstation protocols, to layered communications architectures, Burroughs Network Architecture (BNA) and Distributed Communications Architecture (DCA, from Sperry) • Implementations of other vendor standards such as BSC3270 and SNA from IBM. • Industry-specific standards, mainly for airlines. Some of these standards remain for Unisys airline and travel industry clients, implemented in a third party product. • Extensive implementations of the ISO-OSI model. ClearPath systems contain implementations of the major relevant RFCs 3, together with the necessary electrical and physical network interfaces defined by organisations such as the IEEE (formerly known as the Institute of Electrical and Electronics Engineers) and the International Telecommunications Union (ITU, formerly the CCITT). Common supported standards include:
• Internet Protocols versions 4 and 6 (IPv4 and IPv6). • Telnet and File Transfer Protocol (FTP). • ClearPath systems also support standards for the Internet developed by the W3C and other bodies. The Internet standards use TCP/IP for lower level communications.
2 The model was defined by the X/Open organisation, which later merged with the Open Software Foundation (OSF) to form The Open Group. 3 RFCs (RFC = Request For Comment) are the documents used by the IETF to define standards and to provide a vehicle for additional information...
10 Environment Integrators Few organisations of any size can use only one set of standards; in many cases, different technologies have to coexist. This can be managed by environment integrators, which provide gateways or bridges between different standards – see figure 5. (It can also be done using loosely-coupled middleware, as explained later.)
Storage subsystems
ClearPath Forward System File and DBMS (DMS II, RDMS, DMS, BIS…)
Application Servers (Native: COMS, TIP/HVTIP, Open: Open DTP) Applications
INTEGRATION MIDDLEWARE
ENVIRONMENT INTEGRATORS Java .NET Mobile devices, tablets etc.. Tuxedo
Figure 5: Environment integrators Environment integrators bridge between two standards by converting each standard to the syntax and semantics required by the other. For example, suppose a ClearPath system is running Open DTP and needs to be integrated with a .NET environment. The integrator would convert between the two standards: the Open DTP side thinks it is in an Open DTP ecosystem, while the .NET side sees it as a .NET ecosystem.
Unisys provides a number of environment integration products, which are summarised in table 2. The first column contains the ClearPath environment (COMS, TIP and so on), the second column shows the other environment (Java. .NET and so on), and the third column identifies the product.
ClearPath Environments Other Environments Integration Products Open DTP, TIP/HVTIP, COMS, databases Java Java Resource adapters
EAE, AB Suite .NET, Java Component Enabler
TIP/HVTIP, COMS, MCP and OS 2200 files .NET ClearPath Application Integration Services (AIS)
COMS .NET COMTI Open DTP, TIP/HVTIP, OS 2200 batch Various, including .NET, Java Distributed Transaction Integration (DTI) and some packages COMS, Open DTP, TIP/HVTIP Web browser, mobile devices ClearPath ePortal -Smartphones and tablets Open DTP Tuxedo Oracle eLink OSI-TP
Table 1: Summary of environment integrators
11 Both ClearPath Forward families support Java extensions to ClearPath Forward applications, or new Java applications accessing ClearPath Forward assets, by providing JCA-compliant (Java EE Connector Architecture-compliant) resource adapters to access the native application environments: COMS (MCP), TIP/HVTIP and BIS (OS 2200), and Open DTP (both systems) as well as databases. In the case of applications, the connections are two-way, that is, either end may initiate a request. This allows applications running under TIP or COMS, for example, to invoke Java application components as well as Java invoking the TIP or COMS applications. Figure 6 shows a typical Java configuration.
Database
DBMS
Open DTP/TIP/COMS,.. ClearPath Application
ClearPath Forward
Resource adapter(s)
EJB container
EJB EJB
Web container
JSP Servlets
Java Application Server
Figure 6: Schematic of Java configuration with ClearPath systems
RDMS and DMS on OS 2200, and MCPSQL and DMS II on MCP, all allow Java programs to access the databases through resource adapters, as shown in table 2. The open source product Hibernate may be used for managing persistence in Java environments.
ClearPath Family Resource Adapter Comments Libra (MCP) JDBC for ClearPath MCP driver DMS II data Relational Database Server for ClearPath MCP (MCPSQL) JDBC driver Dorado (OS 2200) RDMS JDBC Driver (RA) DMS RA BIS RA BIS data and BIS scripts
Table 2: Java resource adapters for direct access to ClearPath data
12 Microsoft’s .NET can also be used to extend ClearPath Forward applications or to implement new applications using ClearPath Forward resources. Table 1 shows various options for integrating .NET applications with ClearPath Forward resources.
Python is an increasingly popular language for application development. Support for Python language extensions to ClearPath Forward applications, and new applications using resources on ClearPath Forward systems, is provided in two environments. A Java-based Python interpreter, Jython, is tightly integrated into a Java platform and uses the Java resource adapters to access ClearPath systems, as in figure 6. The development environment is Eclipse. Iron Python is a version available within the .NET Framework, using ClearPath Application Integration Services (AIS) to access ClearPath resources. The development environment is Visual Studio.
Both Java and .NET provide facilities for constructing distributed applications. For example, the Java environment shown in figure 6 may be extended to include other instances of Java application servers. ClearPath resources may participate using the Java resource adapters, as shown in figure 6. Similar environments can be constructed using .NET rather than Java. Figure 7 is a schematic of such an environment.
ClearPath Forward ClearPath Forward DBMS DBMS .
AIS
Java App Server Resource adapter(s) .NET AIS
Windows Java App Server .NET
Windows
Figure 7: Schematic of distributed Java and .NET environments with ClearPath Forward systems
The Open DTP application server available in ClearPath systems also supports distributed environments. Thus, ClearPath implementations may participate in Open DTP ecosystems, where the collaborating systems implement the same application server technology. The platforms may vary as Open Group DTP is implemented under a number of operating systems. Distributed Transactions Any transaction changing data must be able to guarantee data integrity: the data must remain in a consistent state at the end of the transaction. All the updates have to be applied or none is; if the transaction is not completed, the databases and other data stores must be left in the same state they were at the start of the transaction. If multiple data stores are involved, either within a single system or spread across systems, a process called two-phase commit (2PC) can be used to manage the consistency and maintain data integrity. Databases supporting 2PC conform to an industry standard called XA; they are referred to as XA-compliant. ClearPath databases and IBM MQ message queues in ClearPath systems are XA-compliant, as are most other commercial databases such as Oracle and Microsoft SQL Server.
13 Open DTP applications in ClearPath systems may collaborate with other Open DTP implementations in a distributed transaction, maintaining data integrity using 2PC. Java EE applications may take part in distributed Java transactions while maintaining data integrity. In some cases, distributed transactions across different technologies, connected by environment integrators, may also maintain data integrity. For example, Open DTP with DMS II, RDMS or DMS, and Tuxedo with Oracle, can participate in a 2PC transaction because the integrator, eLink OSI-TP, passes the relevant information required for 2PC. Similarly, Open DTP and .NET environments may also participate in a distributed transaction. Unisys provisions for external interfaces in ClearPath Forward systems, as explained above, are comprehensive. They embrace all the major standards required for participation in distributed environments, and they are one of the significant strengths of the two ClearPath Forward families. The ‘More Information’ section at the end of this paper points to sources for detailed explanations of the technology and products provided, illustrated by a variety of case studies. Data Access and Exchange Data resident in ClearPath Forward systems can be accessed and shared for a variety of purposes. Figure 8 shows the interfaces, which are discussed in the following paragraphs.
Storage subsystems
ClearPath Forward System File and DBMS (DMS II, RDMS, DMS, BIS…)
Application Servers (Native: COMS, TIP/HVTIP, Open: Open DTP) Applications
INTEGRATION MIDDLEWARE
DATA ACCESS AND SHARING Direct data access Exchanging data
Figure 8: Accessing and Exchanging Data Direct Data Access Data contained in ClearPath-resident databases and other data sources can be accessed directly from remote systems, for analysis purposes, for example to provide management information. The Java resource adapters run in an external Java environment, as shown in figure 4. Other options use products from Unisys or third parties running in Windows environments, as shown in table 3.
ClearPath Product Function MCP ODBC Access (formerly called Data Access) SQL access to DMS II and other non-relational data stores Enterprise Database OLE DB Data Provider for OLE DB access to DMS II data ClearPath MCP XML Provider for ClearPath MCP Enables DMS II and other data sources to interoperate with other XML-enabled applications and data sources DataBridge Data extraction and transfer from DMS II OS 2200 UniAccess for RDMS ODBC access to RDMS Data Access SQL access to DMS and other non-relational databases
Table 3: Direct Data Access
14 ClearPath systems implement the Server Message Block (SMB) protocol, which provides access to files stored on the ClearPath system from clients such as Windows Explorer as well as programs running on the ClearPath system. The implementation makes it possible for developers and others to use PC tools such as Word, saving the results on a ClearPath system. They would typically do this to take advantage of security and existing file back-up procedures characteristic of systems in a data centre. The implementation also simplifies importing applications and other software written in languages such as C and COBOL. Such applications and software require minimal modification to run in ClearPath environments. SMB is also used in the Java implementation. Exchanging Data Unisys Data Exchange provides selected near real-time data replication and transformation. Use cases include integration of business processes and data analysis. Figure 9 is a schematic of the configuration.
Data transformed as required by target when replicated
Database Database
ClearPath Forward Windows Other system
DBMS Data Exchange DBMS
‘Other system’ could be Apache Kafka
Figure 9: Schematic of Data Exchange
Table 4 shows the source and target data stores for OS 2200 and MCP; more are planned.
Source Target MCP DMS II Microsoft SQL Server, Oracle Database, Kafka
Microsoft SQL Server MCP DMS II
OS 2200 RDMS Microsoft SQL Server, Oracle Database, Kafka
Table 4: Data Exchange: source and target data stores
Figure 9 shows that Apache Kafka is a possible target system for ClearPath Forward. Kafka is a streaming platform which has three key capabilities:
• Publish and subscribe to streams of records, similar to a message queue or enterprise messaging system. • Store streams of records in a fault-tolerant durable way. • Process streams of records as they occur. Kafka is generally used for two broad classes of applications:
• Building real-time streaming data pipelines that reliably get data between systems or applications, • Building real-time streaming applications that transform or react to the streams of data. Connecting with Kafka opens up a considerable range of options for processing data from ClearPath Forward systems. More information about Kafka can be found on Apache’s website. A link is provided in the section ‘More Information’.
15 Loosely-couple Interfaces Some references in the previous sections were made to interfaces with other systems using distributed transactions and environment integrators. However, IT environments almost always comprise a number of collaborating systems, both within a single organisation and externally, including clients, suppliers and government. ClearPath systems support the required interfaces to allow them to participate fully in a distributed environment, increasingly using a service-based approach.
ClearPath Forward systems connect to other systems in a variety of ways – see figure 10:
Storage subsystems
ClearPath Forward System File and DBMS (DMS II, RDMS, DMS, BIS…)
Application Servers (Native: COMS, TIP/HVTIP, Open: Open DTP) Applications
INTEGRATION MIDDLEWARE
LOOSELY-COUPLED MIDDLEWARE Web Services Message Queuing File Transfer
Figure 10: Loosely-coupled Interfaces In distributed systems using loosely-coupled middleware, applications communicate by exchanging messages. No assumptions are made about how an application is written or the environment in which it is running. All that is required is support of the appropriate middleware, and agreement on the form and content of the message. Distributed environments comprising applications running in different technologies – TIP/HVTIP, COMS, Java EE, Open Group DTP, .NET, or CICS, for example – may therefore be constructed using loosely-coupled middleware 4.
Application components in ClearPath systems may collaborate with other applications using the following loosely-coupled technologies. Both ClearPath system families support all the technologies although the implementation approaches may vary.
• Message queuing using IBM’s IBM MQ, formerly called WebSphere MQ. • Message queuing using Microsoft Message Queuing (MSMQ). • Web Services, as defined by the W3C and others. Its use of XML (eXtensible Markup Language) for data and protocol (SOAP) makes it ideally suited to heterogeneous environments. Web Services support includes arbitrary Web Services, which may expose an arbitrary set of services, and the simpler REST (REpresentational State Transfer) Web Services. • File transfer using FTP. Although FTP may not always be considered to be middleware, it is well suited to shipping large quantities of data. It has the advantage of being ubiquitously available. The implementation of IBM MQ in OS 2200 systems is different from the approach used for MCP. A Specialty Partition, the OS 2200 QProcessor, has been introduced for Dorado systems. The MCP version implements the WebSphere MQ queue manager under Windows in a Windows environment, with the interfaces provided under MCP for MCP-resident applications. For MSMQ, the queue manager runs in Windows for both systems, with interfaces provided from the OS 2200 or MCP environments.
4 Although loosely coupled middleware is well suited to inter-connecting applications running in different technologies, it can of course be used in homogeneous environments. For example, two Java EE systems could communicate using Web Services or message queuing. There are good reasons for using message queuing in any environment, for instance to guarantee delivery even when the receiving end of a connection is not available.
16 Web Services with ClearPath systems are provided in various ways. The complete Web services stack – SOAP and so on – can run in the Java environment, using the resource adapters to access applications and data in the MCP or OS 2200 environment. Web Services interfaces can also reside in a Windows environment, using environment integrators or loosely-coupled middleware to interface to the applications. And Web Services, among other standards, are provided by the ClearPath ePortal appliance. The choice of product depends on the client’s requirements and current environment. Security Given the sensitivity of the environments in which ClearPath Forward systems are typically used, encryption is essential to protect data at rest, for example in a database, or in motion between systems. Industry-standard FIPS certified (governed by FIPS PUB 140-2) cryptographic algorithms are available using the Cipher API and CryptoLib API on OS 2200 and MCP Crypt0 API (MCAPI) on MCP.
Algorithms are supported for encryption, decryption, signature generation and verification, and digests that support message integrity. They include Advanced Encryption Standard (AES), with key lengths up to 256 bits, and the asymmetric RSA algorithm with key lengths up to 4096 bits. Support for data in motion includes TLS (Transport Layer Security), Secure Socket Layer (SSL), and Secure Shell (SSH). Elliptic curve cryptography (ECC) has recently been introduced with OS 2200. It has the advantages of RSA in that it uses an asymmetric key approach but uses much shorter key lengths than RSA for an equivalent level of security: for example, an ECC key of 256 bits is equivalent to an RSA key of 3072 bits.
There is of course much more to ClearPath Forward security than cryptography, necessary though it is. The design of both systems families has resulted in exceptional levels of security. The ‘More Information’ section in this paper contains pointers to a number of sources which provide much more detail about all aspects of ClearPath Forward security. Perspective 2: Application Development Application development technology is not standardised, and therefore it cannot strictly be considered as a characteristic of open systems. However, many developers and their managements come to expect certain styles or approaches to be available with systems they regard as open. In particular, popular languages, graphical development tools and IDEs are regarded as necessary, although some developers may need persuading to move from more ‘traditional’ approaches based on preferred text editors.
One of the most popular integrated development environments (IDEs) available for different platforms is the open source product Eclipse. It was developed for Java applications in the first place but has been widely extended using plug-ins. Unisys supports Eclipse for both ClearPath families for Java, and other languages, including C, COBOL, ALGOL and Python (Jython). Unisys-supplied plug-ins provide the necessary integration with the ClearPath systems on which the applications will be deployed. Python applications can also be developed to run in Iron Python in the .NET Framework. The development environment is Visual Studio.
Unisys has long provided tools for rapid application development. These tools work at a high level of abstraction from the ultimate deployment system, an approach which allows developers to focus on the business problem, not the underlying technology. The resulting applications can be executed in different run-time environments, including systems other than ClearPath. The current products are Business Information Server (BIS) on OS 2200, Enterprise Application Environment (EAE) on both families, and Agile Business Suite (AB Suite®) on MCP. EAE and AB Suite can generate for other platforms, typically Windows. On ClearPath systems, they can generate for Open DTP as well as COMS (EAE and AB Suite) and HVTIP (EAE). AB Suite provides a model-driven development environment based on Visual Studio .NET. BIS is a scripting language, with BIS ‘engines’ for runtime on OS 2200, Windows and Linux. BIS supports JavaScript as well as its own scripting language.
17 DevOps is currently a subject of much interest. The goal is to create applications rapidly, responding to new business requirements, making the organisation more agile. It aims to achieve its goals by encouraging a collaboration between developers, users, and system management and operations. DevOps is not a feature of openness: it would, for instance, be possible to maintain a DevOps approach in an otherwise completely self-contained environment using no open standards. However, it is desirable to deliver new application features as quickly as possible. BIS, AB Suite and EAE are tools that enable rapid development. BIS, in its earlier form of MAPPER, was conceived as a tool to enable users to develop applications quickly, without waiting for development groups. The tools clearly facilitate a DevOps style of agile development.
Given the critical nature of many ClearPath Forward applications, care has to be taken to ensure that exhaustive testing, including regression testing, is performed, to avoid instability. However, new features can be developed using Java and .NET, possibly with Python, as non-intrusive extensions to existing applications. An emergency service provides an example. There is a critical application running in a ClearPath Forward system, which manages incidents and resources to tackle them. A new feature was developed using Windows to display maps showing areas under stress during an emergency, and the location of resources: an up to date situation display, in other words. The output devices included tablets and big screen displays. The data sources were taken from the critical ClearPath Forward system, either by direct data access or from a database updated in near real-time by the ClearPath Forward application. The development was completed very quickly, using an agile approach. Perspective 3: Systems Management and Operations Participation in distributed environments requires comprehensive systems management and a high level of automation, including cross-system automation. It is therefore important that management tools can span the systems involved as well as integrate with other management products.
Unisys supplies two systems management products able to work across multiple systems. They are Operations Sentinel (formerly known as Single Point Operations (SPO)) and Enterprise Output Manager (EOM). Operations Sentinel provides automation for multiple systems types, including both ClearPath families. EOM manages output from multiple system types, delivering it to a wide variety of end points.
Other organisations supply management products that can be used with ClearPath and many other systems. They include performance management tools from TeamQuest and Sightline, and workflow management with SMA’s OpCon product.
All the above can integrate with other management products likely to be found in the data centre, including CA Unicenter, IBM Tivoli and HP OpenView. And both ClearPath families provide Simple Network Management Protocol (SNMP) agents, generating events which can be picked up by most management products.
The available tools can be used to implement high levels of automation in cross-platform disaster recovery (DR) and for system updates. Operations Sentinel and OpCon, for example, have been used separately and together to enable multiple collaborating systems of different types to switch operation to a different data centre after the loss of the primary centre. As well as substantially reducing the elapsed time to complete the process, automating DR and system upgrades significantly reduces the risk of problems caused by operator error 4.
Any system, open or otherwise, is the sum of its parts. A typical environment containing ClearPath Forward systems may be composed of hundreds or even thousands of discrete disks, memory modules and processors, from multiple sources. Some of these may be virtual, for example tape drives. However, all are considered to be real, physical hardware components by the operating system and disruption of any must be handled. All systems have expected states for their critical components, but few can automatically return these states to those required when deviations inevitably occur. The Shared Object Manager Application (SOMA) is an extension to Operations Sentinel. One of its roles is to monitor device states and auto-correct them
5 The White Paper ‘Unisys CtearPath Systems Management: Maximising IT Service Availability’ discusses systems management and automation and the tools available with ClearPath systems. A link to the paper can be found in the section ‘More Information’.
18 when they go out of specification. In the case of outright device failure, SOMA warns operators and suggests corrective action. This turns a highly reliable, open system into a self-healing one in the best case. In the worst, it means a system can ask its human monitoring staff for help. Audible alerts, text messages, email, and SNMP-based notification mechanisms round out the open alerting options. ClearPath System Mission-Critical Attributes The definitions of open systems used in this paper are independent of the hardware or operating systems. However, that does not mean that the underlying platforms are unimportant. In the case of ClearPath Forward systems, the platforms provide attributes that make them ideally suited for their primary role of mission-critical transaction processing, for operational and economics 6 reasons.
They include:
• System efficiency. Processor loads of close to 100% can be sustained, together with high levels of security. Thus, the amount and complexity of equipment in configurations, and hence energy and space consumption, are low compared with alternatives. • Multiple concurrent application support under one operating system instance. The systems can handle multiple, critical applications of different types under a single instance of the operating system; the ClearPath operating systems MCP and OS 2200 have always provided a virtual environment for applications, without the need for hypervisors. OS 2200 has a feature called Application Groups. An application group is a partitioning of system software, data files, user programs, their associated messages, and their executions. The purpose of application group partitioning is to create multiple working environments. These working environments act as independently recoverable systems on a single OS 2200 system. There can be up to 64 different application groups on one system. Such application groups can share the services of some system software products. • Software integration. The tightly integrated software and firmware stack supplied by Unisys makes for great efficiency and reduces systems programmer resource requirements, saving time and cost, and reducing risk. • Metering. Charging based on Capacity on Demand and Pay-for-Use business models, using metering technology, can reduce costs while increasing performance significantly. Unplanned changes in demand leading to revenue opportunities can be accommodated immediately. And batch windows are reduced, sometimes to the extent of eliminating an operations shift. Metering is unique to ClearPath systems. • Reliability. System reliability, with fast recovery in the rare event of a failure, maximises availability. The time between system failures is measured in years in some cases. • Security. The high levels of security reduce the risk of data vulnerability through external attack, with consequent adverse economic effects. ClearPath systems protect valuable data from compromise. Evidence for this can be found in a National Institute of Standards and Technology (NIST) database 7, which records security vulnerabilities. As of mid-June 2018, the number of vulnerabilities reported in the database were 6,664 (Windows), 7,199 (Linux), 2,647 (various forms of UNIX), with just three for a ClearPath system (MCP), none of which exposed data. There have been no reported vulnerabilities for OS 2200.
6 A White Paper on the economics of ClearPath systems ‘Delivering Value: The Economics of ClearPath Systems’ covers the subject in detail. Pointers to how to find the paper and others are provided in the ‘More information’ section of this paper. 7 A link to an extract from the database is provided in the section ‘More Information’.
19 Sources of Information There are many Independent, vendor-neutral organisations, working on standards and other collaborative activities, and usually under the domain .ORG. Here is a selected list of organisations, a number of which are mentioned in the text of this paper:
The Apache Software Foundation
For Apache Kafka information
The Carnegie Mellon Software Engineering Institute (SEI)
The IEEE
The Internet Engineering Task Force (IETF): http://www.ietf.org
The International Organization for Standardization (ISO)
The International Telecommunications Union (ITU – formerly CCITT)
The National Institute of Standards and Technology (NIST)
The Open Group
UDDI.xml.org (for information about Web Services)
World Wide Web Consortium (W3C)
The following documents are published on the Unisys Website; the URLs are provided. To find out more about ClearPath Forward open attributes, contact your Unisys representative.
ClearPath OS 2200: Unsurpassed Security
ClearPath MCP: Unsurpassed Security
Unisys ClearPath MCP Independent Security Assessment
McAfee: Unisys ClearPath OS 2200 Security Assessment White Paper
Delivering Value: The Economics of ClearPath Systems
Unisys ClearPath Forward Systems: The Integrated Stack
Unisys ClearPath Systems Management Maximising IT Service Availability
The NIST OS vulnerability latest status
There are many other White Papers and a variety of additional information on all aspects of ClearPath systems. They can be found at ClearPath Forward information.
20 Appendix A: ClearPath Forward Architecture All systems are now Intel-based, including those at the top of the performance range. Unisys has also begun to release the ClearPath Software Series: Unisys provides the ClearPath software and the firmware but not the hardware. Clients have the flexibility of providing their own hardware or virtualisation environment. (A reference architecture is provided to ensure the chosen hardware is able to meet requirements.) This section provides a brief description of the architecture of the ClearPath Forward systems. Details of releases and features of specific systems may be obtained from Unisys through local Unisys contacts or the Unisys website.
Figure A1 is a schematic of a ClearPath Forward Libra or Dorado system, running in a platform supplied by Unisys.
ClearPath Forward Libra or Dorado
Application workload
Operating system (MCP or OS 2200) I/O Unisys Intel Firmware Platform
Firmware operations Dorado/Libra (EPP) OPS PMM ISM OPS
Internal connection infrastructure
QProcessor (Optional) Dorado appliance
Client network
ePortal (Optional) Other systems Appliance (e.g. Java apps)
PMM = Processor/Memory :Module I/O = Input/output OPS = Operations Server ISM = I/O Storage Module
Figure A1: The figure shows the architecture of a ClearPath Forward Libra or Dorado system
In figure A1, the light blue boxes labelled PMM (Processor Memory Module), ISM (I/O Service Module) and OPS represent separate Intel-based components, that is, servers, interconnected through a high speed infrastructure. The upper part of the diagram contains the ClearPath MCP or ClearPath OS 2200 operating system and associated components. The firmware in the PMM maintains application code compatibility while the ISM firmware maintains data format compatibility. More than one server may be used for the PMM and ISM for resilience purposes – the high availability (HA) feature. The lower part of the diagram shows optional appliances: the Unisys ClearPath® OS 2200 QProcessor, which implements IBM MQ, is within the ClearPath system in an Intel-based server; and the ePortal is in a Unisys-supplied Intel server, connected to the client’s network. Other systems may also be connected to the client’s network, including for example, Java applications interworking with OS 2200- or MCP-based applications and databases.
21 The Software Series is relatively new, although PC versions of Libra systems for test and development have long been available. The systems comprise Unisys software and firmware, which provide the security and resilience that users expect from ClearPath systems. Unisys provides guidance on the configuration requirements. The use of third-party hardware for ClearPath Software series facilitates deployment using cloud technology, in private clouds and using external cloud service providers. The Software Series also provides the essential basis for cloud deployment, either in-house or externally in a cloud service provider’s environment. Unisys will be working with partners to develop the additional infrastructure required for private and public cloud deployment. Announcements will be made as and when appropriate.
Figure A2 is a schematic of the Software Series. The system may be installed on bare metal, as shown on the left of the figure, or run under a hypervisor, as shown on the right. Unisys supplies the operating system (MCP or OS 2200) and the firmware; the client or third parties supply the rest. In the figure, NIC = Network Interface Card and HBA = Host Bus Adapter.
Platform, NICs, HBAs Platform, NICs, HBAs
Application workload Application workload
MCP/OS 2200 MCP/OS 2200 Unisys firmware Unisys firmware
VMware/Hyper-V
Client network0 Client network0
Figure A2: Shows the architecture of the ClearPath Software Series
22 Appendix B: Glossary AES: Advanced Encryption Standard – a data encryption algorithm.
API: Application Programming Interface.
ATM: Automatic Teller Machine (aka cashpoint)
BNA: Burroughs Network Architecture.
BSC3270: A half-duplex, multi-point bisynchronous protocol from IBM for the 3270 terminal system.
Container: This term is used in this paper to indicate an application environment that can be a web container, in which JSPs or Servlets execute, and an EJB container, in which EJBs execute.
DCA: Distributed Communications Architecture. This is the Unisys layered communications architecture, which is closely related to the ISO Open Systems Interconnect model. The Telcon system implemented DCA (and other protocols) and ran in the Distributed Communications Processor (DCP) family. Like other vendor architectures, it is superseded by TCP/IP and various middleware standards.
DevOps: The goal is to create applications rapidly, responding to new business requirements, making the organisation more agile. It aims to achieve its goals by encouraging a collaboration between developers, users, and system management and operations.
DTP: Distributed Transaction Processing. Open Group DTP model is a reference model for distributed transaction processing, defined by X/Open originally.
ECC: Elliptic Curve Cryptography: a cryptography system based on a public/private key approach.
EJB: Enterprise Java Bean. A software entity defined by Java EE. It executes in an EJB container.
FIPS: Federal Information Processing Standards. The standards are published as FIPS Publications, abbreviated to FIPS PUBS.
FTP: File Transfer Protocol. A standard defined by the Internet Engineering Task Force (IETF).
IDE: Integrated development environment.
IEEE: Now just called IEEE. Formerly the Institute of Electrical and Electronics Engineers.
IETF: Internet Engineering Task Force.
IoT: internet of Things
IP: Internet Protocol. Used for routing data packets. IPv4 (version 4) has been superseded by version 6 (IPv6), which adds a number of features, but mainly increasing the address size; IPv4 was running out of possible addresses.
ISO-OSI: Open Systems Interconnect model from the International Organization for Standardization.
ITU: International Telecommunications Union. Formerly called the CCITT.
Java/Java EE: Java EE is Java Platform, Enterprise Edition. It was called J2EE (Java 2 Platform, Enterprise Edition) up to release J2EE 1.4; with release 1.5, it was renamed Java EE 5 rather than J2EE 1.5. This is a set of standards defining a Java environment suitable for large-scale applications. Implementations are called Java EE application servers.
JCA: Java EE Connector Architecture.
JDBC: Java DataBase Connectivity. This is the standard defined in Java SE for accessing databases.
23 JSP: Java Server Page. A software entity defined in Java EE. It executes in a web container.
JVM: Java Virtual Machine. This is a software environment in which Java programs execute. It can be implemented on any computer. Implementations are available on ClearPath systems.
Kafka: An open source streaming platform from the Apache Software Foundation.
Linux: This is a UNIX-like Open Source operating system originally created by Linus Torvalds. It is available from a number of suppliers.
Microservices (architecture): Microservice architecture is a method of developing software applications as a suite of independently deployable, small, modular services in which each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal.
Middleware: Middleware is the software that connects network-based requests generated by a client to the back-end data the client is requesting. It is a general term for software that serves to “glue together” separate, often complex and already existing programs.
NIST: National Institute of Standards and Technology.
ODBC: Open DataBase Connectivity. This is an API for accessing database management systems, independent of programming language, database system, and operating system.
OSI-TP: A protocol defined by the International Organization for Standardisation (ISO) for distributed transactions. Includes facilities for ensuring consistency of multiple database updates.
OLE: Object Linking and Embedding
POSIX: Portable Operating System Interface (for UNIX).
Python: A programming language gaining in popularity.
REST: See Web Services
RFC: Request for Comment. An RFC with a number identifies a document defined by the IETF. If the RFC defines a standard, it is called ‘normative’. RFCs may also provide clarification, for example on how to implement a standard.
RSA: A cryptography standard using a public/private key approach. Named after its inventors: Rivest, Shamir and Adleman.
SAN: Storage Area Network.
SEI: (Carnegie Mellon) Software Engineering Institute.
Servlet: A software entity defined in Java EE. It executes in a web container.
SMB: Server Message Block protocol for sharing resources such as files and printers.
SNA: IBM’s System Network Architecture.
SNMP: Simple Network Management Protocol.
SOA: Service-Oriented Architecture.
SOAP: A protocol defined by the W3C for interconnecting nodes in a distributed service environment. It was originally an acronym for Simple Object Access Protocol, but is now just a name.
SQL: Structured Query Language, a language for accessing databases.
SSH: Secure Shell, a public key security protocol.
24 SSL/TLS: Secure Sockets Layer/Transport Layer Security. Standards for providing secure communications between systems using encryption.
TCP/IP: Transmission Control Protocol/Internet Protocol. TCP and IP are important protocols defined by the IETF force for constructing networks. The term ‘TCP/IP’ is also used to indicate the entire set of standards for networking defined by the IETF.
UNIX: This operating system was originally developed by AT&T at Bell Laboratories in the early 1970s. The specification is now owned by The Open Group. There are many variations of UNIX.
Web Service(s): A set of technologies and standards defined by the W3C and others for communicating between different systems. Web Services includes arbitrary Web Services, which may expose an arbitrary set of services, and the simpler RESTful (REpresentational State Transfer) Web Services.
W3C: World Wide Web Consortium.
XA: This is a system-level interface between a resource manager (RM) and the transaction manager (TM) in The Open Group DTP model. XA provides the 2PC capability. A database or other resource manager that supports it is called XA-compliant.
XML: eXtensible Markup Language is a language defined by the W3C for encoding messages and protocols in a machine-independent way.
2-PC: 2-Phase Commit. A technique for ensuring that different databases, possibly in different systems, are consistent at the end of a transaction, i.e. all are updated or none is. About the Author Now an independent consultant, Peter Bye was a systems architect in Unisys, based in London. His special area of interest is networked computing, including communications networking, middleware, and architectures. He has many years of experience in information technology, working as a programmer, analyst, team leader, project manager and consultant in large-scale projects in banking, transportation, telecommunications and government. He has also worked in software development centres, during which time he spent two years as a member of an international standards committee working on systems management.
He has worked for extended periods in Sweden, Denmark, Finland, Norway, the USA, France and Spain, as well as the UK. He has presented at a wide variety of conferences and other events, and is the author of a number of papers on networking, systems management and middleware. He is the co-author of a book on middleware and system integration – IT Architectures and Middleware: Strategies for Building Large, Integrated Systems (2nd Edition) – which was published by Addison-Wesley.
25 More Information Want to know more? Contact your Unisys representative.
For more information visit www.unisys.com
© 2018 Unisys Corporation. All rights reserved.
Unisys and other Unisys product and service names mentioned herein, as well as their respective logos, are trademarks or registered trademarks of Unisys Corporation. All other trademarks referenced herein are the property of their respective owners.
Printed in the United States of America 08/18 18-0458