The Actor-Spectator-Producer Pattern: a Software ... - CiteSeerX

Towards an Open Architecture for the Integration and Interoperability of Financial Markets Systems Fethi A. Rabhi1 1

School of Information Systems, Technology and Management The University of New South Wales Sydney 2052, AUSTRALIA Email: [email protected]

Abstract. The recent years have witnessed considerable developments in the area of distributed systems, software and applications, particularly linked to the popularity of the Internet and the provision of Web-based services. This paper studies current developments and trends in the area of financial markets systems. It investigates opportunities for the integration of existing and new services through a distributed software architecture and describes some of its essential features. It also discusses the development process of distributed applications based on the use of design patterns.

1

Introduction

The world of business faces new challenges as a result of the rapid expansion of the Web and Internet technologies. An increasing number of individuals and organisations are already providing a huge quantity of information and services over the Web. In particular, the financial sector has seen dramatic changes over the past decade, especially in relation to the provision of on-line information services (e.g. real-time share-trading) and support for a wide range of financial transactions services. A consequence is the move towards new business models such as global markets, 24-hour trading and straight-through processing. This trend is set to continue over the next decade. A large number of services are now accessible from the Web using PCs, laptops and even mobile phones connected to a variety of communication devices ranging from LANs to wireless telecommunication networks. They offer a convenient interface to a variety of back-end systems ranging from databases to decision-support systems. As the number of such services grows at a rapid rate, the possibilities offered to business users are endless. In addition, it is very hard to keep track of new developments such as new services being added or enhanced. For these reasons, there is an increasing need for truly cooperative applications that require access to

-1-

several services simultaneously according to some business model. For example, such a service can automatically check the latest financial information, carry out shares trading and settlement in a way that requires minimal user intervention. When considering the underlying technologies supporting these services, they are far from presenting a consistent and integrated picture. As a result, the development of cooperative applications is an ad-hoc, very demanding and time-consuming process. It typically requires an enormous effort of low-level programming and is further complicated by the fact that the number of services is dynamic, diverse and very large. The next section studies this problem in detail by focusing on the area of financial markets systems. It identifies the existing levels of interconnectivity between applications and the standards in place. It shows that the majority of applications still exchange data at the lowest levels. Section 3 investigates a software architecture to address these problems and proposes a development methodology for cooperative applications based on the concept of design patterns. Section 4 concludes this paper.

2

Interconnectivity levels in financial markets applications

First, we must define what we mean by applications “cooperating” with each other as there are several (and often conflicting) definitions of widely used terms such as messaging, middleware, data formats etc. Figure 1 shows what we consider to be the three levels of interconnectivity between different software components in a cooperative application. The service level presents an application-based layer. Underneath, the middleware level defines the interfaces of communication between the various software components. A symmetric level is the data format level which defines the format of the data being exchanged between the software components. At the bottom of the figure sits the network level which provides connectivity at the network level. These are now explained in more detail in the rest of this section.

SERVICE LEVEL DATA FORMAT LEVEL

MIDDLEWARE LEVEL

NETWORK LEVEL Figure 1: Four levels of interconnectivity in distributed applications

-2-

2.1 Network level This level provides support for the exchanges of data packets at the network protocol level. For security reasons, most financial systems cooperate using private or purpose-built networks. An example is the SWIFT Transport Network (STN) [15] which based on the X.25 protocol. As communication software is non-standard, this is a very expensive solution. Other than for historical reasons, there is less and less interest in cooperating at this level because of the low level nature of the corresponding programming interfaces. Another reason is that nowadays every networked platform supports the Internet Protocol (IP), which is the common reference for a suite of networking protocols based on TCP/IP. Even private networks are now moving towards IP-based solutions (Intranets and Extranets). For example, SWIFT is now developing a new generation of interactive services (called SWIFTNet) using an IP-based network called the Secure IP Network (SIPN) [15]. 2.2 Data format level A data format refers to the content of the data being exchanged between software components. In particular, there is a need to represent non-trivial data in particular application areas. A data format usually is accompanied by communication software which is used to convert application data into a standard message, then communicate this message to another communication software which converts it back into application data. This way, two completely different databases can exchange data with each other. The eXtensible Markup Language (XML), which is an emergent set of open standards managed by the World Wide Web Consortium (W3C), is gaining widespread industry support for content management, delivery and presentation at the Internet-based front-ends of distributed applications. In parallel with XML developments, a number of international organisations were already working towards the adoption of common standards in the financial area. One of such standards is the Financial Information eXchange (FIX) protocol [2] for communicating securities transactions between two parties. Since FIX does not define how data is transported, an XML version of FIX called FIXML has been defined [3]. Another standard is FpML [4] which enables e-commerce activities in the field of financial derivatives. In each case, a working group defines a Data Type Definition (DTD) that defines the XML tags and how they can be legally combined. These DTDs can then be used with XML parsers and other XML tools to rapidly create applications to process and display the stored information in whatever way is required. Using XML for these applications is a lot simpler than creating a completely new messaging standard from scratch every time, with a lot more scope for re-using the work of others.

-3-

Other related standards include ISO15022 [6] which defines a standard for messages in Banking, Securities and related financial services. This standard is suitable for inclusion within an XML format. Another standard is SWIFT’s messaging service which is called FIN [15] runs on its private network (STN) and enables financial institutions to exchange standardised financial messages worldwide. 2.3 Middleware level Middleware refers to a software layer whose role is to ensure that a program can invoke operations defined another program even if the two programs are written using different languages and are running on different machines possibly using different networks and/or operating systems. The emphasis is that there must be a common interface of communication between these two programs. The most common example of a middleware standard is OMG’s CORBA and its associated Interface Definition Language (IDL) [7]. A CORBA service component is a program which typically exhibits a set of operations (services) defined in IDL and is accessible from any other component in the network. Another popular middleware platform is Enterprise Java Beans (EJB) [1], only suitable for software components written in the Java language. The future CORBA Component Model (CCM) standard [8] has several features of EJB so it is expected that the two middleware standards will converge into a single one in the long term. Beside the basic CORBA facilities, the OMG also manages sets of domain interfaces for key operational domains such as Manufacturing and Medical Health. In the financial sector, an OMG Task Force (called FDTF) has adopted a Currency standard. Other financial standards in process include a General Ledger Facility, Party Management and Risk Management. Another relevant OMG Task Force is the OMG Electronic Commerce Task Force working on various standards such Electronic Payment and Negotiation Facility. For more information about CORBA Domain Interfaces, see [7]. 2.4 Service level This is the highest level in the hierarchy. It offers business services in a way that “hides” the underlying data formats or middleware platforms. It represents the appropriate level for defining multiple-service cooperative applications that correspond to particular business models. Within the financial markets area, the main business transaction cycle and its associated services is summarised in Figure 2. Pretrade analytics includes program trading and order routing and post-trade analytics includes surveillance, compliance and risk management.

-4-

Pre-Trade Analytics

Registry

Trading

Settlement

Post-Trading Analytics

Figure 2: Services involved in financial markets transactions Currently, there are very few cooperative applications that cross the boundaries between different systems so the transaction cycle still requires human intervention at various points. Some recent examples of CORBA-based integrated financial applications are described in [7].

3

A software architecture for financial markets applications

3.1 The need for interoperability and integration Figure 3 summarizes the various standards discussed in the previous section. We have shown that most systems still cooperate at the lowest level of interconnection. Because of rapid technological changes and the prevalence of Internet technologies, these systems and their associated infrastructures are rapidly becoming obsolete. Therefore, there is a need for increasing interoperability between networks, systems and applications so that data sharing costs are reduced and new business models could be implemented.

-5-

Trading Settlement

THE SERVICE LEVEL FIX

Trade Analytics

CORBA

FIXML EJB/CORBA Components XML Java 2

THE DATA FORMAT LEVEL FIN

SwiftNet Services

IP Networks THE NETWORK LEVEL

Extranets/ Intranets

SWIFT Network

INTERNET

IP

SWIFT Transport Network (STN)

Figure 3: Interconnectivity levels in financial markets systems

-6-

3.2 General features of the software architecture The proposed software architecture main’s objectives are: •

To enable some software components to offer services and other software components to make use of these services, therefore facilitating the development of cooperative applications.

•

To allow software components to interact with each other regardless of the languages, operating systems and communication medium used to implement them.

•

To provide rules for defining new components and specify how components interact with each other.

In other words, the proposed architecture identifies a set of standard basic building blocks suitable for the integration of existing services as well as the construction of cooperative multi-service applications. To ensure wide portability and wide applicability of the associated components, our software architecture is based on both Internet-based data formats and middleware technologies. All communication is handled through CORBA and all messages exchanged between components are encoded using the eXtensible Markup Language (XML) and its variants (e.g. FIXML) depending on the nature of the transaction. Integrating XML and CORBA allows: XML data received from Web-based systems to be efficiently processed by CORBA systems providing data access and query services to the Web; XML data to be sent back to Web systems; CORBA Objects be queried through XML based messaging protocols etc. Although interoperability is the most visible aspect of CORBA, it also provides security to authenticate users and control access to resources, error handling and other support functions that are useful in a distributed environment. A number of techniques for making CORBA-compliant objects to exchange XML documents already exist. The OMG is currently working on a standard for XML documents in IDL. 3.3 Design patterns The definition of a software architecture is only a first step. The next one is to define the guidelines for building cooperative applications according to some essential criteria (e.g. performance, security, reliability, etc.). Our solution revolves around the concept of design patterns, originally proposed by Gamma et al. [5]. The idea of design patterns is to facilitate the reuse of well proven solutions based on experiences from developing real systems. Given a library of common “patterns” for designing software, developers choose the pattern that is most adapted to their needs. Patterns are often associated with object-oriented systems because of their support

-7-

for reusability through classes and objects. To our knowledge, there have been no previous attempts at defining design patterns specifically for financial markets applications. DESIGN AND IMPLEMENTATION ENVIRONMENT Application 1

Pattern User Interface

Pattern Library Application 2

User Code Additional Info. Application 3

Figure 4: A Pattern-Based Tool for Developing Cooperative Applications The documentation of design patterns is informal and varies in the literature. In most descriptions, the information associated with the pattern (such as context, problem and solution) is presented in a textual form. Our previous work [12] takes this concept one step further. Instead of a design pattern being an informal entity, it proposes to make it part of a “Computerised” Design Tool that captures the dynamic computational behaviour of the pattern in some sort of software library that has been properly designed, implemented and tested. All is left to the application developer is to generate an instance of the pattern through the provision of some parameters that are specific to their application. Figure 4 illustrates this process. Let us assume a complete cooperative application is represented as a shaded box. A design pattern will therefore imply that a significant portion of the code can be reused in different contexts. The idea behind our approach is to place this “generic code” in a library, with some well identified “gaps” that need to be filled by the user through a graphical interface. In our terminology, these gaps represent the parameters of the pattern. It is worth pointing out at this stage that a cooperative application is much more than a piece of software. It is the combination of several pieces of software working together in a certain way (largely determined by the pattern definition). A

-8-

similar tool has been developed for cooperative applications in areas as diverse as High Performance Computing [11,9], Fault-Tolerant Computing [10] and Distributed Real-Time Systems [13,14]. A prototype tool, based on our proposed architecture, is currently under development.

4

Conclusions and future work

This paper discussed the design and implementation of cooperative applications in the area of financial markets. It identified the different levels of interconnectivity and reviewed the emerging standards. It also proposed a software architecture which allows components to interact with each other at the service level. Based on this architecture, it advocated the use of design patterns and an associated software tool to facilitate the development of cooperative applications. The advantage of this approach is that it provides the appropriate level of abstraction for the development of cooperative applications in the face of rapid technological changes. Future work will concentrate on finalizing the architecture and developing appropriate design patterns which encapsulate existing practice and experiences with a proven track. Another area of future work is building an experimental development tool which supports the reuse of components through the pattern definition and allows automatic code generation. The main advantage would be that software maintenance will only involve making adjustments to the parameters. At worst, it will involve the use of a different pattern which is a far cry from redesigning the software from scratch.

5

References

1.

S. Asbury and S.R. Weiner, Developing Java Enterprise Applications, J. Wiley and Sons, 1999.

2.

FIX Protocol Ltd., The Financial Information Exchange Protocol (FIX), Version 4.2, March 2000, available from www.fixprotocol.org.

3.

FIX Protocol Ltd., FIXML: A Markup Language for the FIX Application Message Layer (White Paper), available from www.fixprotocol.org.

4.

FpML.org, FpML Version 1.0, Trial Recommendation, 25 September 2000, available from www.fpml.org.

5.

E. Gamma and R. Helm and R. Johnson and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley, Professional Computing Series, 1995.

-9-

6.

International Organisation for Standardisation (ISO), ISO 15022 Web Site, www.iso15022.org.

7.

The Object Management Group (OMG) Web Site, www.omg.org.

8.

The Object Management Group (OMG), CORBA Component Model Request For Proposal, OMG Document orbos/96-06-12, 1996, available from www.omg.org.

9.

B.O. Osoba and F.A. Rabhi, A Multigrid Skeleton based on BSP, Proc. Formal Methods for Engineering Special-Purpose Parallel Systems, Kaslik, Lebanon, December 2000, IEEE Computer Society Press.

10.

M.E. Outram and F.A. Rabhi, A Skeleton for the Design of Parallel FaultTolerant Systems, Proc. DCCS’2000: 16th IFAC Workshop on Distributed Control Systems, Sydney, November/December 2000.

11.

P.J. Parsons and F.A. Rabhi, Generating parallel programs from paradigmbased specifications, Journal of Systems Architectures, vol. 45, no. 4, 1998, pp. 261-283.

12.

F.A. Rabhi, A Parallel Programming Methodology Based on Paradigms, In Transputer and Occam Developments, P. Nixon (Ed.), IOS Press, 1995, pp. 239-252.

13.

F.A. Rabhi and T. Devillers, A Software Architecture for Distributed Virtual Environments: the Actor-Spectator-Producer Pattern, Proc. The First AsianPacific Pattern Languages of Programming Conference, KoalaPLoP'2000, May 2000, RMIT Technical Report, Melbourne, Australia.

14.

F.A. Rabhi, H. Cai and B.C. Tompsett, A Skeleton-Based Approach for the Design and Implementation of Distributed Virtual Environments, 5th International Symposium on Software Engineering for Parallel and Distributed Systems, Limerick, Ireland, June 2000, IEEE Computer Society Press, pp. 13-20.

15.

S.W.I.F.T., Building for tomorrow: a white paper on the features and benefits of SWIFT’s next generation of products and services, 1999, available from www.swift.com.

-10-