GB2355820A - An information service - Google Patents

Abstract

An information service comprises means for publishing information originating in a data processing system for subscribers. The information service is the central part 1 and comprises a rule/event engine 2, an analytic engine 3, and a data acquisition and distribution bus 4. The service 1 supports globally distributed systems including: servers (10) for operations such as operational risk, credit risk, and market risk operations; modules (11) for operations such as securities, collateral data, and legal risk data operations; third party applications and data sources (12); distribution operations (13) such as MIS reporting, operational reporting, and event broadcasting; and front office and back office acquisition processing (14).

Description

2355820 "An Information Service"

INTRODUCTION

Field of the Invention

The invention relates to distribution of information on financial institution networks.

Prior Art Discussion

As present, there are a number of risk or exposure evaluation systems which perform exposure calculations on financial data. For example, United States Patent Specification No. US5446885 (IBM describes such a system in which rules are stored as objects in a relational database. The rules are presented in a manner which allows the user to easily modify them.

PCT Patent Specification No. W09630850 (Hogan Systems) describes use of risk rating data structures to process staged data and determine credit risk data. PCT Patent Specification No. W09703409 (Cedel Bank) describes a system for management of credit exposure between coutnerparties having credit support agreements. This processing is performed on a global basis.

Objects of the Invention While such systems are generally quite effective for performing credit risk functions, there is a need for improved interchanging of data between the risk calculation system and other processing systems and management information systems.

SUMMARY OF THE INVENTION

According to the invention, there is provided an information service comprising means for publishing information originating in a data processing system for subscribers.

In one embodiment, the publishing means comprises a notifier which mediates between a data processing system and a bus accessible to subscribers.

In one embodiment, the notifier comprises means for listening for availability change records in a data processing system.

In one embodiment, the notifier comprises means for marshalling data into objects and for publishing the objects on the bus.

In one embodiment, wherein the notifier comprises a management and control component and a publisher component.

In one embodiment, the notifier further comprises an object factory 25 component.

In one embodiment, the notifier further comprises a transaction logging component.

In another embodiment, the publishing means further comprises a client monitor which subscribes to the bus.

In one embodiment, the monitor comprises means for detecting objects on the bus which have associated parameter values exceeding pre-set limits, and for updating a subscriber with information relating to said objects.

In one embodiment, the monitor comprises means for receiving active updates to limit objects in its process space and for causing the objects to be updated on a subscribing client.

In one embodiment, the information service comprises a channel availability service comprising means for brokering channel availability for a subscriber such as the monitor.

In one embodiment, the channel availability service is CORBA-based.

In one embodiment, the bus comprises a hub messaging framework over a transport layer and a message store provider.

In one embodiment, the publishing means comprises a rules engine comprising means for acting as a client for monitoring events according to user-defined configurable rules.

In one embodiment, the rules engine comprises means for executing a predefined action automatically upon occurrence of an event.

In one embodiment, the rules engine comprises means for executing a wide range of types of actions.

In one embodiment, the rules engine comprises means for linking a plurality 5 of rules to form a complex tree of actions and reactions.

In one embodiment, the rules engine comprises a business rule agent comprising means for analysing business events to generate output events, and a visual interface for subscriber users.

In one embodiment, the visual interface comprises means for presenting a table in which the columns are associated with attributes of an output event.

In one embodiment, the information service further comprises a mapper for 15 inputting data in a pre-defined format to a data processing system.

In one embodiment, the mapper comprises means for integrating data into a data processing system.

In one embodiment, the mapper comprises a dealer service having a dealer module within a distributed object-oriented environment.

In one embodiment, the dealer service comprises a deal factory and dealer components which act as CORBA servers.

In one embodiment, the dealer service comprises CORBA clients which interact with the servers through proxy reference objects which are local to the client address space.

DESCRIPTION OF THE INVENTION

Brief Description of the Drawings

The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which:-

Fig. 1 is an overview diagram illustrating operation of an information service of the invention at a high level; Fig. 2 is a diagram illustrating the information service architecture in more detail; 15 Figs. 3 and 4 are diagrams illustrating mapping operations; Fig. 5 is a more detailed diagram of the architecture; Figs. 6 and 7 are diagrams illustrating messaging sequences in the information service components; Fig. 8 is a diagram showing a JMS bus architecture; Fig. 9 is a diagram showing a JMS API; Fig. 10 is a diagram showing an interface framework; Fig. 11 is a diagram showing a notifier in more detail; Fig. 12 is a table showing notifier signals; and Figs. 13 to 23 inclusive are sample screen displays for use of the information service.

Referring to Fig. I the overall context of an information service 1 of the invention is illustrated. It is in an international financial services context, in which the information service is the central part 1 and it comprises a rule/event engine 2, an analytic engine 3, and a data acquisition and distribution bus 4. The service 1 supports globally distributed systems including:

10: servers for operations such as operational risk, credit risk, and market risk operations; 11: modules for operations such as securities, collateral data, and legal risk data operations; 12: third party applications and data sources; 13: distribution operations such as MIS reporting, operational reporting, and event broadcasting; 14: front office and back office acquisition processing.

The information service 1 is referred to also by the term PARIS (EroActive Risk Information Service). The service 1 enables data to enter systems, particularly risk management systems such as that marketed by GEIS under the name RYMTm. It also enables information to be distributed to a diverse set of clients, as illustrated in Fig. 1. Thus, the service 1 allows developments such as shifting of information reporting from passive information blocks to intelligent data cubes, which are objects containing both dedicated data, aggressions, and intelligence to zoom from business level to transaction level and back. Also, it facilitates a shift from point-to-point communication using a request-answer process to one-to-many event driven information distribution, and also a shift to multi-dimensional representation with integrated graphics and data.

Referring now to Fig. 2, the service 1 comprises mappers 20 which interface between various systems 21 and a risk management system 22 for data input. The service 1 also comprises a notifier'25 connected by a hub 26 to an information distribution bus 27. The bus 27 is monitored by an opportunity monitor 30, an active violation (or limits) monitor 31, a market risk engine 32 and a special interest rules engine (SIREN) 33.

The data mappers 20 provide a standard and scalable method of integrating all types of data into the system 22. This data could relate to deals from either a bank's dealing room or back office operations. Alternatively, the data could be price and rate data from a market price vendor for use in a bank's market risk server, or counterparty rating data for a credit risk server. The data mappers 20 enable integration of data from legacy systems and also the ability to integrate with a next generation of risk servers The data mappers 20 include a CORBA dealer service which provides the functionality of a dealer module within a distributed, object-oriented environment. The DealFactory and Dealer components of the system act as CORBA servers in a CORBA-based client-server architecture as shown in Fig. 3. Their interfaces are defined in CORBA IDL. CORBA clients interact with the servers through proxy reference objects that are local to their client address space. The on-the-wire- transport protocol is HOP.

The possible clients that might communicate with the dealer service are shown in Fig. 4. Four types of client are indicated - marked 1 to 4. The first of these is a GUI client for deal entry and limit check. Such a client might have the functionality of a current R)W PCI client. The other three examples all show different ways of feeding deals into R)OA from external systems. In each case, mapping functionality translates the deal structure produced by 15' the external system into the structures (objects) expected by the CORBA IDL interface. This mapping process could make use of)ML technology.

In example 2 the deal producer uses the RXM CORBA interface directly, i.e. it has a proxy object in its address space and invokes method calls on this.

The advantage of this approach is that deals can be entered synchronously into RYM and can be scoped in the same transaction as deal production. Errors reported by RYM can be caught and the transaction aborted. The corresponding disadvantage is that the two systems are tightly coupled and the time spent waiting for deals to be entered into RXM may affect the deal production process.

In example 3, the deal producer is de-coupled from the CORBA interface. Deals are stored in a separate log file and then read by a separate gateway process, which is a CORBA RXM client. Deals that are rejected by RXM are stored in a separate log for subsequent clean-up, In example 4, The deal producer outputs its deal onto a bus in a standard format, probably based on XML. A separate gateway process subscribes to the Deal channel on the bus and gets notified when any new deals arrive. These are the translated into the RXM IDL object format and entered into the RXM system.

Various devices subscribe to the information published by the notifier (event receiver and hub). The active violation monitor 31 is a client which enables any user or subscriber to be actively informed of market or credit events within an area of interest to which they have subscribed. The monitor 31 subscribes to information alerts in the form of credit or market events. Thus, the users or subscribers are actively informed of precisely the information they want to receive instead of needing to detect it from vast passive blocks of data available in a bank's trading operations. The monitor 31 passes the information subscribed through any Active X compliant tool such as a Microsoft ExcelTm spreadsheet.

The rules engine (SIREN) 33 is a client which monitors events in the bank's trading operations against a set of dynamically pre-defined rules. The events that SIREN monitors are chosen by the user. They could be the activities of the bank and its employees or the market and the bank's counterparties. Once an event or series of events is being monitored, the SIREN executes the pre-defined action. The action could be anything from executing a simple Java routine to calling the risk manager on his mobile telephone. The engine 33 has the ability to link multiple rules and create a complex tree of actions and reactions dependent upon the activities that it is monitoring. It enables the application of rules to a large amount of data and releases the intelligence embedded within that data before executing an informed action. A Risk Manager or other users can dynamically define the rules that SIREN operates.

A typical application of SIREN is to provide an opportunity monitor for dealers. The opportunity monitor watches for market opportunities that fit the needs of the trading operation and alerts dealers to specific market areas and counterparties that match the bank's preferred criteria for trading at that time through broadcast messages. The dynamic nature of defining rules means that the SIREN could be used to focus the bank!s trading on a daily or intra-day basis. The dynamic rules environment created by SIREN enables a bank to move away from a passive reactive mode of operations into an aggressively proactive mode that leverages the positive effect of risk management on the bank's profitability.

In Fig. 2, a separate opportunity monitor 30 is illustrated. This operates as a client in a manner similar to the monitor 31, however, opportunity monitoring may be implemented exclusively by the rules engine 33 in which the rules may be easily and dynamically changed.

The market risk engine 32 manages the risk of losses in on- or offbalance sheet positions arising from movements in market prices, including interest rates, spreads, exchange rates, equity values, and commodity prices. It is a server connected downstream of the management system 22.

The information service 1 avails of improvements in hardware 5 communication technology. The software level uses CORBA-compliant and JMS middleware which support publish-and-sub scribe techniques to provide a standard "data bus" capability both for data capture and for information delivery. The service 1 allows:

-ease of interfacing using standard models and conversion methods, global local awareness whereby local requirements around the globe are incorporated and respected, -end-to-end data integrity and transaction tracking, - ease of maintenance for both global and local standards, and consistent aggregation and consolidation. 20 The publish-and-subscribe basis for the information distribution avoids the need for bi-directional communication in many instances and so is much simpler than heretofore.

Referring to Fig. 5, the output bus 27 comprises a Java Messaging Service (JMS) bus framework 40 which facilitates the active transportation of limit and availability objects between the risk management system 22 and interested clients. The notifier 27 (which may, together with the on-line update function 44 and the RWS 45 may also be referred to as an "event receiver") mediates between the bus 40 and the system 22, listening for Availability (AVL) change records, marshalling the data into objects and publishing the objects on the bus 40 as clients. The rules engine 33 and the monitor 31 subscribe to the bus 40. The rules engine 33 correlates information and takes actions in a manner which is completely configurable.

An active limits service (ALS) 48 receives active updates to limit objects in its process space and this causes the objects to-be updated on the subscribing client.

The bus 27 also comprises a CORBA bus 41 which is primarily used for data entry by a trade entry client 42 and a data entry service 43. The system 22 provides on-line updates 44 to a reporting workstation (RWS) 45.

The RWS 45 outputs data to a limit availability service 46 connected to the CORBA bus 41. An ExcelTMspreadsheet application 47 is connected to both the JMS bus 40 and to the CORBA bus 41. This is a client which both inputs limit parameter values to the information service 1 and receives outputted information.

Referring to Fig. 6, a sample message flow is illustrated. This involves a request for availability from the active limits service (ALS). The arrows illustrate the following sequence of requests.

1. The ALS 33 requests availability from the Availability CORBA service.

2. The Availability CORBA service requests availability from the Reporting Workstation (RWS) 45 database.

3. The RWS 45 sends the availability to the Availability CORBA Service 41.

4. The CORBA service 41 sends the Availability to ALS 33.

5. The ALS 33 subscribes to the limit/availability channel for a particular counterparty/location pair (or whatever keys are used to select particular data). This is a call within the ALS which starts listening for anything published on the relevant channel.

When limit/availability data is modified, then the client needs to be notified of that event if he has subscribed to that information. The message flow if the change results for a deal entered through the PCI is shown in Fig. 7. The sequence is as follows.

1. A deal is entered for the PCI, which sends a message to the RXM 22.

2. RXM 22 Notifies RWS 45 and then the Notifier 25 of the change, using Availability (AVL) messages.

3. The Notifier 25 publishes the changes onto the limit/availability bus 40, to any subscribers.

4. The Active Limits Service 48, which has been listening on the relevant channel, picks up the change and updates the screen.

Referring to Fig. 8, the JMS framework bus 40 is illustrated in more detail. 5 It comprises four layers as follows:- - a manager 50, - a rules manager 51, - - an active object cache 52, - an interface 53, The layers 50 to 53 are over a transport provider 54 and a message store provider 55. They implement the hub 26 of Fig. 2.

The interface 54 offers a typeless interface for transporting Java objects between applications connected to the bus. This layer includes the functionality for content-based subscription through the specification of predicates. The higher level layers of the interface provide the means for an application to deal with typed interfaces (via Java.Beans or CORBA) that 20 reflect the information & business event model being used within the bank-

However, the CORBA/DCOM standards currently support remote method invocation on objects actually resident on central servers. This type of architecture can lead to bottlenecks, especially if an object reference to a 25 popular event object is distributed to a large client population. The interface 54 uses Java to physically transport information and business event objects to the subscribers. If the subscriber is actually a CORBA/DCOM client, then the event object will be resident in a local Java gateway process that is connected to the interface 54.

The interface 54 has two internal layers, a Transport layer and a MessageStore. The Transport layer abstracts any messaging protocol such as multicast, point to point, HTTP, RMI, HOP.

The MessageStore layer represents a persistent store of messages to allow durable messaging. Durable, in this context, means that networks can go down, machines taken off line and the con-ununication can still continue by using a persistent store of messages for recovery.

There are three main configurations of using the Transport and MessageStore layers.

Only use the Transport layer to achieve non-durable publish / subscribe Use the Transport layer and MessageStore for recovery to achieve durable publish / subscribe Only use a MessageStore and poll at a defined polling frequency to achieve durable publish / subscribe The JMS API follows a simple design pattern for the creation of message publishers and subscribers, shown in Fig. 9.

The active object cache 53, provides a decoupled scalable object cache. The aim of this mechanism is to reduce requests that are traditionally sent to the server and therefore reduce the possibility of server bottleneck, reduce network traffic and improve the performance of the client application. It provides an active cache of Java objects, which can be specified using predicates. Predicate based subscription coupled with active containers allows active queries. It also provides an 'active object' interface to define the characteristics that are required to notify interested client applications that a change has been made to the associated object. This notification mechanism uses the standard Java property change architecture.

The rule framework 51 is an Event Condition Action (ECA) rule framework for building distributed event-based architectures. Active database management systems provide mechanisms for the implementation of active behaviour in terms of ECA-rules. The framework 51 allows the use of active mechanisms in heterogeneous and distributed environments. This functionality is provided by a component that allows the definition and processing of ECA-rules and is separated from a particular DBMS, which allows the use of active capabilities on its own, and not only as part of the DBMS functionality.

Events reflect the movement and flows of information around a system.

Conditions are used to include or exclude data from a process or a process from the data. When some event occurs and some condition is true then some processing will take place that is relevant to that event and the state of the system at that time. Coupled with a high level event a condition might further refine what process is to be executed.

Actions define the processing that will take place should an event occur and some condition is true. The event and condition together act as a precursor to some action occurring.

The manager 51 is a distributed management architecture that provides an Active Management Information Base so that managed applications can be actively notified of changes to their managed objects. The Manager uses the introspection information of Java to provide generic management tools (e. g. configuration editor).

The management architecture is built upon the rule framework 51 to use the active model for management information, and provide the flexibility to build management intelligence into the architecture using ECA rules.

The management architecture has three main components Management Information Base (MIB) Management services User/service applications that can be managed.

The third party components use are as follows.

OrbiXWebTM This is an implementation of the Object Management Group's (OMG) Common Object Request Broker Architecture (CORBA) which maps CORBA functionality to the Java programming language. It combines a powerful standards-based approach to distributed application development with the flexibility and ease of use of the Java environment. It has:

- Full Naming Service (OrbixWeb Names) - Interface Repository - Server Manager utilities 5 Orbix COMETTM OrbixCOMETTm consists of a number of basic components:

1. The container executable - this provides a single EXE file that acts as a loader for the DLL files required for support.

2. Implementation DLL - this provides the compliant interfaces for the product such as the Factory interface. Note that this can be viewed as the interface between the developer and the adapter.

3. A set of DLLs, which constitute the bridge for the point of view of mapping and protocol, support. Various help files, error message files etc.

Microsoft Java Virtual Machine TM Microsoft Java Virtual Machine TM offers support for transfer between Java objects and COM objects, which is to implement in PARIS Pilot as an 25 interface to ExcelTM.

The notifier 25 is a very important part of the information service 1. It allows events writing within the system 22 to be comprehensively distributed. These events may identify when limits have been exceeded and may be used to notify availability changes in real time. The notifier 25 is shown in more detail in Fig. 7. It comprises the following components.

60: a management and control component, 61: a transaction logging component, 62: a Bean Factory component, 10 63: a publisher.

The notifier manages a dialogue as shown in Fig. 12 to process transactions supplied by the RWSUPD module.

Monitoring the Notifier Error logging The Notifier maintains two separate Log files in two sub directories. 20 Each file has the timestamp embedded in the name, and they are not cleared by the application. The status log file receives every action performed by the Notifier, including every string received from the R)M and every string sent (including logging information). 25 The other Log file holds every transaction received from RXM - in the same format as RXM sends.

The log files pre-pends every line written with a time stamp that the event occurred, including errors (see below).

Transaction Time Stamp Log There is an additional file, the time StampLog. txt file, which holds information of the last received event in a character string, with the format:

<id> <yyyymmdd> I <counter> Status Management The Notifier broadcasts transactions using an interface 54 multicast on the 15. channel:

geis.paris.notifier.transactions.

Management events (errors and RYM shutdown events (ZZQ etc)) are broadcast on:

geis.paris.notifier.management And clients are given a still alive message every 30 seconds on:

geis.paris.notifier.heartbeat.

Communication & restart management The notifier traps shutdown messages from RX1\1 and broken connection errors, broadcasts the errors and logs them to the status file then finally broadcasts a Notifier shutdown event on the management channel, before shutting itself down.

Monitoring Notifier via an Explorer.

An Explorer written using the Java swing components is used to browse file systems, JDBC/ODBC complaint databases, and JMS message streams. For JMS, channel (topic) subscription information is displayed in the tree (right hand side), together with message type and number of messages received. Detailed information about the messages (JMS message header and message 15 body content) is displayed in the table component on the right hand side.

The notifier 25 does not require presence of the RWS 45 for on-line updates as this functionality is incorporated in the notifier 25.

The system 1 comprises various monitors. The monitor 31 is a specified client for'managing limit violation for risk managers. Another, monitor, called an Active Limits Service (ALS) is also a specialised client which monitors subscription of exposure information.

In more detail, the ALS acts as a CORBA client to a CORBA limit server. It makes initial on demand requests to a CORBA server for limit and availability information. The ALS also acts as a JMS subscriber onto the limit and availability bus. The quality of service required is limited to reliable multicast and not guaranteed delivery. The subscription is based on topics and not on predicates. The topic structure is based on counterparty, product family, place, and exposure code. Furthermore subscription require only one of these attributes to be specified.

The user interface is illustrated in Fig. 13. It consists of a selection window, which allows the user to specify the requested limit/availability, a table window which displays the summary data, and a detail window which zooms on a specific set of data.

Each window is active reacting to external events that arrive from a JMS based bus. As a change event is handled and passed into the ALS, the ALS modifies the window that is affected by changing the values displayed and modifying their colour to yellow (configurable). This colour stays for a default time period (configurable) of 60 seconds and then assumes the original colour.

The selection criteria may be selected in a pop-up list. The pop-up list is built from the RWS static tables (customers, product family, etc.) through the CORBA service. These selection criteria are used to formulate a request to the CORBA service for the initial limit check information and thereafter are used to formulate the subscription topic against the availability bus.

Referring to Fig. 14, a standard scrollable table view of limit data is displayed for each of the selected limits/exposures. The data can be sorted based on any column value. The negative availability (limit in excess) is highlighted using the red colour. The table is active; reacting to external events that arrive from a JMS based bus. As a change event is handled and passed into the ALS, the ALS modifies the row that is affected by changing the values displayed and modifying their colour to yellow (configurable). This colour stays for a default time period (configurable)of 60 seconds and then assumes the original colour.

Referring to Fig. 15, from the data summary, the user can drill down to the detail of a Limit/Availability. The detail screen is still active, showing an the related data to an AVL transaction.

The rules engine (SIREN) 33 comprises the following two main components:

0 A business rule agent that analyses business events to generate relevant output or 'PARIS events', and 9 A visual interface GUI to allow users to monitor these 'PARIS events'.

This simple rule-based approach provides the system with the capability for demonstrating the power of business rules when used to add value to the functionality offered by the information service 1.

The GUI presents a view on to PARIS events that are generated either by specifically configured business rules or explicitly by the CORBA service.

The GUI presents a 'table' where the columns are associated with the attributes of the 'PARIS Event'. These fields are date and time, description and priority. The priority field of the 'PARIS event' is used to determine the order in which events are displayed, the colour in which the event should be displayed, and the amount of time that the event should remain in the table.

Events are displayed in priority order; for example events of priority 4 will be displayed before events of priority 3, and so on. Within each priority band, the events are displayed in date/time order. The user has the option of selecting one or more events and removing them from the list. Alternatively, the engine 33 will maintain the list of events and remove them after a preconfigured time period. Each priority band will have its own associated time period, allowing higher priority events to remain in the table longer than low priority events. The configuration for the engine 33 is stored in a Java property file.

The business rules associated with the rules engine 33 reside in one or more rule business agent processes that run within the distributed architecture. These processes are configured with the rule base 51.

The business rules define particular target events that they wish to receive. When such an event occurs, the rule session is initiated to process that event. The rule session can then perform a number of tasks, including waiting for an event sequence, accessing reference information to check some conditions or perform defined actions. The actions may be to modify some reference 20 information or publish new events.

The responsibility of the business rules is to monitor for events that may be generated by the service 1, apply certain conditions and then finally generate meaningful 'PARIS events' that can inform interested users that the 25 monitored condition has occurred.

Configuration of the business rules is performed using a modelling tool in the rule framework layer 51 of the JMS bus framework 40. This tool enables a rule administrator to define business logic in an Event Condition Action (ECA) paradigm. When the rules have been 'compiled', they can then be distributed to existing running agents that will automatically switch to the new version of the rule base.

The types of rules that can be applied will be dependent on the information published by the service 1.

The spreadsheet limit interface 47 comprises two components: 10 1. COM server - To provide access to business objects over CORBA, and updates via the JMS bus.

2. Front end - User interface 15 The requirement is for an automation server that is capable of firing events. Whether this server takes the form (or name) of a COM/DCOM server, OLE 2 server or Active X control makes no difference, and these terms are used interchangeably in the description that follows.

Automation servers provide objects with a standard set of interfaces based around the IDispatch interface and dispinterfaces, with optional source & sink support for OLE events.

The advantages of almost complete code re-use between standard Java clients and OLE container clients (in this case Excel), are considerable, and so an approach using Microsoft Java Virtual Machine Tm has been chosen.

Other issues that must be -taken into account include the subtle differences between the COM run time object model and the Java object & class model. In general COM objects are more limited in their support for Object Orientation than Java classes. Notable differences lie in the areas of object 5 construction, class static members and inheritance.

There are also subtle differences between object interface conventions between the COM and Java 'worlds'. For example, Java property change events sink to COM containers, however conventional automation servers would provide objects capable of firing events to a series of specific (although still anonymous) event handlers. Another subtle area is that of navigating between objects.

All of these problems can be overcome (& hidden) by creating a simple decoupling layer. This will take the form of a Java package with a precise and simple interface. Underlying changes will not affect the main 'entry' object's dispatch interface.

The COM client is embedded as part of the ExcelTm client. The COM client and COM Server are programmed to provide support for the RXM data elements required to drive the updates within the cells of the spreadsheet. The ExcelTm spreadsheet is constructed in a similar manner to the Active Limits service, where the user can subscribe to selected exposure points and subsequently be notified of any change made to the exposure through the PARIS distribution bus. As the ExcelT14 process is driven by MicrosoftTm COM process and the data is delivered through a JMS process, the Microsoft Virtual Machine is utilised as a bridge.

Java classes must be registered for use via COM via the MS JVM. Visual J++ projects are used to manage type library creation and Java class registration.

The COM server is capable of running in process, out of process, or on another machine (DCOM). An in process server is used, due to the significant increases in speed available due to the lack of any marshalling requirement (albeit at the loss of memory address space protection).

A type library is generated to include the main entry object, and any event types generated (from the decoupling package), together with the standard PARIS business objects.

The standard type library (generated by Visual J++) allows for early binding to all typed COM objects specified, except where they are used as method arguments or return values. There is a slight overhead in using late method binding in these scenarios, and compile time VB type safety is lost. This could be partially remedied by hand crafting a type library using MIDL & ODL, as required.

The COM server is capable of being hosted in any OLE container that supports automation. For example, MS Visual BasiCm and ExcelTm could be used to write front ends. Alternatively, the COM server could be used from within WordTm for report creation and from within PowerPoint for dynamic presentations. The COM server must be referenced from within ExcelTm by specifying the location of its type library. The selected Java objects can then be used from Excel VBATm as standard VB/OLE objects. COM Objects defined in the type library can be browsed from the VBA object browser, as shown in Fig. 17.

The spreadsheet application 47 subscribes to particular Availabilities based on a customer code, product family code and exposure code. Updates to these objects will be notified by updating and highlighting the relevant spreadsheet row, as shown in Fig. 18.

A Trade Entry and Static Limit Check (Availability Check) operates through 10 a CORBA service. This CORBA service operates to:

1. RWS 45 database to get access to static data (i.e. Customers, Places, 2. RXM dealing functions to process deal entry and availability check.

Regarding instrument types supported, four instruments have been identified through two product families illustrating single currency product and multi currencies product. The products are the following:

9 Placement 0 Future Rate Agreement 0 Spot 0 Forward Forex A Logon screen is activated to fill the identification of the MW User and Branch to be sent to RYM. The screen shown in Fig. 19 is used. Both Deal Entry and Availability Check use the same screen, but each product has its own screen. Some of the data can be filled using pop-up list coming from the RWS 45 database (Customer, Place, etc.). The screen has buttons at the bottom to select the appropriate action:

Deal Entry e Availability Check Deal Reversal The screen shown in Fig. 20 is a Placement screen.

In response to the user request, RXM answer will be interpreted initially by a short notice:

The Worst Case violation for a deal entry request.

The Maximum deal size which can be done for an availability check request.

This notice is shown in the screen of Fig. 2 1.

More details may be displayed: 20 All the'violations for a deal entry.

All the availability for a availability check.

These are shown in a table in a screen as shown in Fig. 22. 25 The Deal must be confirmed, as shown in Fig. 23.

The invention is not limited to the embodiments described, but may be varied in construction and detail.

Claims (25)

Claims

1. An information service comprising means for publishing information originating in a data processing system for subscribers.

2. An information service as claimed in claim 1, wherein the publishing means comprises a notifier which mediates between a data processing system and a bus accessible to subscribers.

3. An information service as claimed in claim 2, wherein the notifier comprises means for listening for availability change records in a data processing system.

4. An information service as claimed in claim 3, wherein the notifier comprises means for marshalling data into objects and for publishing the objects on the bus.

5. An information service as claimed in claim 4, wherein the notifier comprises a management and control component and a publisher component.

6. An information service as claimed in claims 4 or 5, wherein the notifier further comprises an object factory component.

7. An information service as claimed in any of claims 4 to 6, wherein the notifier further comprises a transaction logging component.

8. An information service as claimed in any of claims 2 to 7, wherein the publishing means further comprises a client monitor which subscribes to the bus.

9. An information service as claimed in claim 8, wherein the monitor comprises means for detecting objects on the bus which have associated parameter values exceeding pre-set limits, and for updating a subscriber with information relating to said objects.

10. An information service as claimed in claim 9, wherein the monitor comprises means for receiving active updates to limit objects in its process space and for causing the objects to be updated on a subscribing client.

11. An information service as claimed in any of claims 8 to 10, wherein the information service comprises a channel availability service comprising means for brokering channel availability for a subscriber such as the monitor.

12. An information service as claimed in claim 11, wherein the channel availability service is CORBA-based.

13. An information service as claimed in any of claims 2 to 12, wherein the bus comprises a hub messaging framework over a transport layer and a message store provider.

14. An information service as claimed in any preceding claim, wherein the publishing means comprises a rules engine comprising means for acting as a client for monitoring events according to user-defined configurable rules.

15. An information service as claimed in claim 14, wherein the rules engine comprises means for executing a pre-defined action automatically upon occurrence of an event.

16. An information service as claimed in claim 15, wherein the rules engine comprises means for executing a wide range of types of actions.

17. An information service as claimed in any of claims 14 to 16, wherein the rules engine comprises means for linking a plurality of rules to form a complex tree of actions and reactions.

18. An information service as claimed in any of claims 14 to 17, wherein the rules engine comprises a business rule agent comprising means for analysing business events to generate output events, and a visual interface for subscriber users.

19. An information service as claimed in claim 18, wherein the visual interface comprises means for presenting a table in which the columns are associated with attributes of an output event.

20. An information service as claimed in any preceding claim, wherein the information service further comprises a mapper for inputting data in a pre-defined format to a data processing system.

21. An information service as claimed in claim 20, wherein the mapper comprises means for integrating data into a data processing system.

22. An information service as claimed in claims 20 or 21, wherein the mapper comprises a dealer service having a dealer module within a distributed object-oriented environment.

23. An information service as claimed in-claim 22, wherein the dealer service comprises a deal factory and dealer components which act as CORBA servers.

24. An information service as claimed in claim 23, wherein the dealer service comprises CORBA clients which interact with the servers through proxy reference objects which are local to the client address space.

25. An information service substantially as described with reference to the accompanying drawings.