CA2248096C - Collection of events within a distributed object system - Google Patents
Collection of events within a distributed object system Download PDFInfo
- Publication number
- CA2248096C CA2248096C CA002248096A CA2248096A CA2248096C CA 2248096 C CA2248096 C CA 2248096C CA 002248096 A CA002248096 A CA 002248096A CA 2248096 A CA2248096 A CA 2248096A CA 2248096 C CA2248096 C CA 2248096C
- Authority
- CA
- Canada
- Prior art keywords
- event
- client
- filter
- objects
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/542—Event management; Broadcasting; Multicasting; Notifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/465—Distributed object oriented systems
Abstract
A Distributed Object System includes an Event Collection Mechanism (14) whic h receives information on the creation, deletion and actuation of objects with in the system. The Event Collection Mechanism passes on the collected events to an Event Dispatch Mechanism (16) with which user applications may register. The Event Dispatch Mechanism forwards details of events to the User Applications, according to the criteria selected by the user. A method is provided for linking all reported events back to the object which was ultimately responsible for their creation.
Description
COL~ECTION OF EVENTS WITHIN A
DISTRIBUTED OBJECT SYSTEM
The present invention relates to the collection of events within a Distributed Object System.
Distributed Collly~lling is an area of co~ ulil~g in which distinct software modules running on physically separate computing nodes can communicate with each other, and can request each other to p~.rullll tasks.
The development of object-oriented technology has given Distributed Computing extra impetus in recent years~ and the convergence of the two 0 technologies has resulted in Distributed Object Technology.
As the number and complexity of these objects has increased, so have the problems involved in establishing exactly what is ha~l,e~ lg in such a system. Although a number of so~vare support tools are available to system designers and m~int~iners, they are ~;ullently rather unsatisfactory. Various 5 tools are currently available. for example. for debugging conventional "single process" software, allowing developers to step through the code in the software and to inspect the state of the program. There are also one or two tools applicable to object-orientated programming that enable prograrnmers to "visualise" objects within conventional software by showing the creation and 2 o deletion of objects.
Difficulties arise, however, since such conventional tools are really not sufficiently powerful or flexible for the needs of ~lçsi~rs and ~ ..ers of large Distributed Object Systems.
Accordillg to a first aspect of the p~ese.lt invention there is provided 2 5 a Distributed Object System having a plurality of objects, each object having an associated filter, the filter being arranged to illlerc~l m~ss~ges sent or received by its col~ ,onding object and to forward inform~tion represent~tive of said mess~g~s to an Event Collector.
The invention also extends to a corresponding method, and in particular extends, in a second aspect of the invention, to a method of characterising a Distributed Object System having a plurality of objects, the method CO~ lg providing each object with an associated filter which is arranged to intercept mesc~ges sent or received by its corresponding object and to forward information lC~.S~ ~tali~re of said messages to an Event Collector, the Distributed Object System being characterised according to the mess~Ps received by the Event Collector.
The messages collected by the Event Collector may be representative of a predefined class of events, for example the class of interactions between objects and the deletion and creation of objects. Preferably. the Event Collector may forward collected events to an Event Dispatch Mech~ni.cm which processes the events and forwards them to one or more User Applications. These User Applications may take a variety of different forrns.
including Visualizer Applications. Fault Detecting Applications. Control Applications and Charging Applications. In a preferred embodiment. several different User Applications (objects) may be running simultaneousl . and each may be independently configurable. Depending upon the particular requirem~ntc, the configuration may be automatic or user-defined.
In one forrn, the invention may provide a mech~nicm for creating a stream of events, where each event consists of either the tr~ncmicsion of a meSc~ge from one object to another, or the creation or deletion of an object.
The system may be installed without intrusive ch~nges to the code of the object th~elves. F~ll~e~more~ it may allow more than one individual to vi~ lice interactions in the system at any one time, allowing each individual to see only the actions that are relevant.
~l~f.,,~ ely, in another emborlimPnt the system may provide fault reporting and/or fault recovery services within a Distributed Object System.
The system accordingly provides a tool or series of tools which can collect information, in a well defined way. from the various objects within a Distributed Object System. The information thus collected may then be used to analyse the system, for example to find out what has happened during a s system failure or other unexpected event. Equally importantly, the information collected may be used to assist svstem ~ÇCigners who are attempting to explain the system to other people who are not directly involved in development. Conventionally, Distributed Object Systems are extremely difficult to explain, and the present invention in at least some forms, will improve the "information transfer" process from developers and designers to technical collaborators and customers.
The invention may be carried into practice in a number of ways and one specific distributed object system incorporating the invention will now be described~ by way of example. with reference to the accompanying drawings, S in which:
Figure I illustrates the Remote Procedure Call in a distributed processing environment;
Figure 2 shows and overvie-v of the svstem according to the preferred embodiment of the present invention;
Figure 3 shows the way in which filters are used to intercept mess~ges being sent and received;
Figure 4 illustrates the operation of the filters;
Figure S shows how interactions propagate between objects;
Figure 6 shows how mPsc~g~s with keys are sent between objects;
2s Figure 7 correspon(lC to Figure 6, but shows the interaction with an additional object;
Figure 8 shows how the preferred vic~-~1i7~r application registers with the event ~iCp~tf~ meçll~nicm;
Figure 9 shows the event diCp~ch mer~l~nicm forwarding information to the visualiser application;
Figure 10 shows an exemplary screen shot from the preferred vi.cll~li7~tion application;
Figure 11 shows an exemplary structure for a distributed processing environment (DPE) that may be used in association with the present invention;
and Figure 12 shows a hardware view of a platform for use with embodimPnts of the present invention.
Before describing the preferred embodiment of the present invention, it may be useful to set out some general backeround information on Distributed Processing Environments (DPEs) generally.
A large number of DPEs conform to a de-facto standard called the 5 Common Object Request Broker Architecture (CORBA). The CORBA
standard was created by the Object Management Group (OMG) which is an international consortium comprising a lar~e number of computer companies, software vendors and other interested parties.
Most DPEs use a style of interaction called the Remote Procedure Call 20 (RPC), illustrated generally in Figure 1. In the RPC model, a client object 10 sends a m~c.c~e 11 to a remote server object requesting a particular operation.
The server object 12 executes the code which corresponds to this operation, and then returns control to the client 10 by means of a reply mess~ge 13.
Typically, the outgoing mess~ge 11 CGnt~ s the name of the operation to be 2s invoked along with the arg~m~nt.~ to the operation, while the reply mec~age contains the name of the operation that was invoked along with the results of the operation.
W O 97137304 PCT/GB97tO0834 There are other interaction styles, but most may be thought of as being derived from the conventional RPC model. For exarnple, an alternative interaction style used in CORBA is the "one-way" style. In this model, the message to invoke an operation is sent to the server object, but in the me~ntime the client object cl)ntin-les to execute its own code. When the server object completes the execution of the operation concerne-l no m~occ~e is sent back. This may be viewed simply ac a conventional RPC in which there are no results, and in which no confirmation is sent back from the server object to the client object.
0 Turning now to Figure ~. there is shown an overview of the preferred embodiment of the present invention. The exemplary system is implemented by means of three main subsystems. The first subsystem 14 is an Event Collection Mech~nicm~ concerned with the collection of events which arise from the creation and deletion of objects and the interactions between them.
As may be seen from the drawing, the Event Collection Mechanism receives inforrnation from a plurality of distributed objects 2,4 which may be widely spaced within the computing environment. For example, one object may be running on one physical computer. and another on another physical computer connected to the first by a conventional local area network or even a wide area 2 o network. The second subsystem 18 takes the forrn of a Vi.cll~li7~r Application which allows users of the system to view the interactions, configure the way in which they view the interactions, and decide which interactions to view.
Several vi~ li7çr applications 18a,18b,18c may be operational at one time.
The third and final subsystem comprises an Event Dispatch Meçh~ . l6;
2s this takes the stream of events from the collection mech~ 14 and ~ ~licp~trhes it to each of the individual Vi~ li7er Applications 1 8a, 1 8b, 1 8c. It will be understood, of course, that the Event Collection Meçh~ni~m 14, the Event Dispatch Mech~ni~m 16 and the Vi~ li7~r Applications 18 may all be considered as objects in their own right.
Figure 3 shows in more detail the interactions between the individual objects and the ~vent Collection Mec~l~ni~m 14. For ease of reference, the reference numerals used for those elements corresponding to the RPC model 5 co~espond to the numerals used in Figure 1. As may be seen, the event collector 14 collects events 26.28 which are tr~n~mitted by filters 20,22 associated respectively with the client object 10 and the server object 12. The filters themselves may comprise the filters present in the CORBA conformant product Orbix. Orbix is a commercial software product available from Iona Technologies. This allows sofh~ are to be inserted ~ hich will be run during the arrival, ~licpatçh, reply and return of messages (object interactions).
Accordingly, the event collector 14 collects information relating to the tr~nsmi~sion of a message from one object to another (that is the invocation of an operation on one object by another). or the creation or deletion of an object.
15 The filters are associated with the objects in such a way that they interceptmessages being sent and received. but without requiring any changes to the objects themselves.
Figure 4 illustrates the operation of the system in practice. Figure 4a shows the situation before Object A invokes a request on Object B. Figure 4b 2 o shows the situation when the request is invoked. The outgoing message 11 is intercepted by Filter A, and a reporting message 30 is passed on to the Event Collection Merh~nicm- It will be understood, of course, that when an Object is created or ~eleted the corresponding filter will also be created or deleted, thereby enabling an event for this to be genclaled as well. The Event 2 s Collection Merh~nicm ~imlllt~neously collects events from all the active objects within the system.
All of the events collected by the Event Collection Me~ni~m 14 are then passed on, in a continllous stream, to the Event Dispatch Meçh~ni~m 16 W 097/37304 PCT/GB97tO0834 (Figure 2). Of course, collecting information on every mçss~e that passes between objects~ and on the creation and deletion of every object, is likely to result in information overload. Typically, the user may be interested only in what is happening to particular objects, or to particular classes of objects, and 5 it would therefore be useful to provide some method of establishing which events are of interest. The way in which this is achieved will now be described.
It should first be noted that in a Distributed Object System, when an object in the system interacts with another, further "knock-on" interactions 10 may well ensue. This is illustrated in Figure 5, in which an interaction between objects 32,34 has created "knock-on" interactions with further objects 36,38. In the l)re~-lcd embo~ t a mech~ni~m is provided whereby the subsequent "knock-on" interactions may be linked back to the original interaction which triggered them off.
The wa- in which this is achieved may be seen with reference to Figure 6. Each object in the system is given the unique key or identifier, this key beine stored in association with the respective filter. Then. if an object (say Object A) calls on the services of another object (Object B), the key of Object A is prop~g~tecl to Object B which takes on this key until it has finished 2 o servicing the request of Object A. It then discards the key of Object A. and returns to its own key again.
Figure 6a illustrates the situation prior to Object A invoking a request on Object B. As will be seen, the filter 20 associated with Object A contains a unique Key A, and the filter 22 ~csoci~ted with the Object B cont~inc a unique 2 5 Key B.
Figure 6b shows the situation as Object A invokes a request on Object B. An outgoing mecc~ge 11 is passed between Object A and Obiect B, this message being i~llerc~,pted as previously described by the filter 20 which WO 97/37304 PCTtGB97/00834 generates a reporting message 30. The filter 20 attaches to the message 11 its own key, Key A, and that is passed on to the receiving filter 22. which currently contains Key B. When the mess~ge cont7~inin~ Key A arrives, the filter 22 takes on Key A in replacement for its original key, and passes the rest 5 of the message on to Object B.
Figure 6c shows the situation while the request is being serviced by Object B. As will be seen, Object B's filter 22 has now taken on Key A.
Figure 6d shows what happens when Object B completes the request, and sends back a reply message to Object A. As the mçcs~ge is sent, Object 0 B's filter 22 takes back on its original key. Kev B. The reply message is received by the filter 20, and passed on to Object A. Simlllt~neously. the filter 20 generates a further reporting message 30'.
which is passed on to the Event Collection Mech~ni~nl 14 (Figure 2~.
Thus, all of the events which occur as a result of the initial interaction 5 sent from Object A to Object B can be associated via Key A with Object A.
The Event Collection Mec~nicm understands that all of the reported events emanate from Object A, since both of the reporting messages 30.30' include within them Key A.
A slightly more complex scenario mav be seen in Figure 7, where 2 o Object B in turn invokes the services of a third object. Object C.
Figure 7a shows the situation before Object A invokes a request on Object B.
Figure 7b shows the situation during the invoking of the request. A
reporting mPss~e 44, incl~ ing Key A, is sent to the Event Collection 2 5 Mecll~ni~m inforrning it of the invoking request.
Figure 7c shows the situation dunng the time that Object B is servicing the request of Object A. It will be noted that the filter 22 of Object B has taken on Key A.
W 097/37304 PCTtGB97/00834 Figure 7d now shows what happens when, prior to control returning to Object A, Object B needs to invoke a request on another object 40 (Object C).
Object C has associated with it its own filter 42 which at this point contains Key C. The filter 22 intercepts the message and appends to it its own key s which is currently Key A. It also provides a further reporting mec~ge 46 to the Event Collection Mecl-~ni~m, which itself contains Key A indicating that the initial interaction em~n~te~ from Object A.
Figure 7e shows the situation during the time that Object C is servicing the request from Object B. Object B's filter 22 contains Key A. as does now Object C's filter 42.
Figure 7f illustrates the sending of the reply back from Object C to Object B. Once the reply has been sent. the filter ~2 dispenses with Key A
and reverts to its original key, Ke- C. The filter 22 intercepts the reply message and sends out another reporting message 4~ to the Event Collection 15 Mech~ni.~m Again, this contains Key A since it em~n~tes from the filter 22 which currently contains that particular key.
Finally, Figure 7g shows what happens when Object B completes its request, and returns control back to Object A. The repl- message is sent back from Object B to Object A, and Object B's filter 22 takes on again its original 2 o key, Key B. On receipt of the reply message, Object A's filter 20 sends out yet another m-oss~e 50 to the Event Collection Mech~ni.cm. Once again. this message will contain the Key A, since that is the key currently associated with the filter 20.
It will be seen, thele~ e, that the key is propagated from one object to 2 s the next, by adding it to the m~ss~ge at the sçn(ting filter, and removing it from the mess~ge at the receiving filter.
Using this meçll~ni.~m, it is now possible to select particular events or classes of events for filrther analysis. For example, if a user of the system wished to vi.cu~lice the whole sequence of events which had occurred as a result of an interaction emitted from Object A. all he would need to do would be to select only those events having associated with them the relevant key, namely Key A.
Further details will now be given, with reference to Figures 8 and 9, on the Event Dispatch Mech~nicrn and its connection with the Visualizer Application.
As events are collected by the Event Collection Mer~l~nicm, they are forwarded to the Event Dispatch Mechanism 16. The Event Dispatch 0 Mech~nicm receives details of all events collected by the Event Collection Mech~ni.cm 14. and is arranged to forvard those particular events that the user is interested in to the Visualizer Application 18.
As may be seen in Figure ~, the Event Dispatch Mechanism 16 incorporates within it an object, kno~vn as the Event Di.cp~tcher Factory 52.
responsible for creating fi~rther objects 54 knoun as Event Dispatchers. Each Event Dispatcher is responsible for sendin~ events to a particular Visualizer Application. A user who wishes to ~ iew a particular subset of events runs the Visualizer Application Object 18, which then re~isters as indicated by numeral 56 with the Event Dispatch Mech~nicm 16.
As indicated in Figure 9, several individual instances (objects) of the Vin~li7Pr Application 18 may in practice be running at once, each of which has registered with the Event Dicp~tch Mech~nicm 16. On each registration, the Event Dispatcher Factory 52 creates a new Event Dispatcher Object 54 which passes information as indicated at 58 to its corresponding Vic-1~li7Pr Application. Each Vic~ r Application 18 may be configured di~elllly, and may require information on a different subset of the events which have been collected (or are being collected) by the Event Collection Mech~rli.cm 14.
The necess~. y filtering is carried out by the respective Event Dicp~tch~.r 54 WO 97~7304 PCT/GB97/00834 which passes on only that information which has been requested by its individual Vicl-~li7er Application.
The Vi~ i7er Application 18 may take many forms, having a variety of ~ont-ends, the preferred version being illustrated schematically in Figure 10. The user of the Visualizer Application sees information displayed graphically within a large window 60. Within a ~vorkspace 62 of the window are displayed the various objects that the Visualizer Application has been configured to show. Typically, the display will show a plurality of object icons 64, connected by arrows 66. Each icon 64 represents a particular object, with the arrows representing interactions between the objects. Certain ofthe arrows 67 and/or the object icons 68 may be displaved in a different colour to indicate the active (current) interaction and/or object. In the preferred display, the most recentlv displayed interaction is shown in red; as another event arrives, that becomes the active interaction and the previous actiYe interactionbecomes grey.
The windo-v 60 may further include a tool bar 70 having a status display 7~ and a pluralitv of buttons 74 whereby the user may configure the display to his or her requirements.
The preferred capabilities of the Vicll~li7er Application are set out 2 o below:
Configurable modes:
(a) Step mode - in this mode, events are stored in a queue at the application, and a counter on the application shows how many events are currently queued. A step button allows the user to 2s move sequPnti~lly through the stored events, displaying one for each click of the step button;
(b) Run mode - in this mode the application does not queue the interactions that arrive, but attempts to display them irnrnediately. There is a control which allows the user to pause the display of events, in which case they are temporarily stored in the queue until the play button is pressed. The application imposes a minitnl~m time between the display of events which is configurable by the user.
Live or recorded event streams:
(a) In live mode, events are received from the event collection and dispatch systems as described above;
(b) in play from file. a sequence of events is fed from a stored file;
0 (c) In record to file. a live sequence of events id displayed~ and at the same time, recorded into a file for playback at a later date.
Configuration of display:
The Visualizer Application can be configured bv loading in a configuration file which contains information about:
(a) Objects - the configuration file allows the user to configure which objects are to be displayed~ what position they are to be displayed in, what colour should be used for the object, and what category of display behaviour it should conform to;
(b) Events - the configuration file also allows the user to configure which incoming events are to be displayed, and what user-friendly narne should be displayed by each event.
Configuration of key:
This allows the user to receive events which occur as a result of actions taken by an object (or set of objects) which has been configured with a certain 2~ key.
Interactions are displayed on the screen only if all four of the following criteria are met:
(a) Interactions must have the same key as that which was configured into the Visualizer Applications (unless no key has been configured);
(b) Interactions must originate from an object which has been configured to be of interest;
5 (c) Interactions must terrninate at an object which has been configured to be of il.t~,le~l.
(d) Interactions must have a mess~ge name which has been configured to be of interest.
As mentioned above, objects may be configured to conforrn to certain behaviours. The following behaviour t,vpes are exemplary, and additional tvpes may be added at any time by modifying the Visualizer Application:
Type 1 object - This type of object is always visible on the screen of the Visualizer Application.
Type 2 object - This type of object becomes visible when an event is received that tells the Visualizer Application that the object has been created. and becomes hidden when an event arrives that corresponds to the deletion of the object.
Type 3 object - This type of object becomes visible when an interaction is displayed that goes to the object, but is hidden by the arrival of a deletion event.
In other embodiments (not shown) the Vi~ 1i7~r Application 18 may be replaced by other objects that can make use of the information collected by the Event Collection Mecll~ni~m. For example, a Fault-Reporting 2 5 Application could provide for fault-monitoring of a Distributed Object System.
Such an application might include the production of system alarms where une,~,e~led events have occurred, along with error-recovery objects designed to modify the operation of the system in the event of an alarm. The system could, for instance, be closed down entirely automatically in applopliate circumstances, or other fault-recovery objects could be run. The system of the present invention may therefore be useful not only to system designers and ~n~ins,~iners, but also as a means of monitoring an Operational Distributed s Object System.
In yet a further embodiment (not shown) the Vi~ i7~r Application may be replaced with a Charging Application. The events collected by the Event Collection Mech~ni~m may then be used to charge for the use of objects or services.
Reference will now be made to Figure l l. which illustrates the infrastructure aspects of the engineering model defining the preferred Distributed Proces~in~ EnvironmPnt (DPE). The DPE is an infrastructure (of a type known per se) that supports the interactions of the various objects previously ~iscl~csed The purpose of the DPE is, amongst other things, to 15 shield the application programs from the heterogeneous and distributed natureof the underlying environment, and to provide a mech~ni~m that allows objects to interact without a knowledge of the details of the particular computing node they are active on. The DPE defines four types of entity: a DPE kernel 8 l l, a kemel transport network 90l, DPE stubs. and DPE servers 809. The kernel 20 transport network 90l is linked as shown in the Figure with a plurality of interlinked computing nodes 8 l0.
The DPE kernel defines a core set of communications, storage and processin~ capabilities (for e~..~;le a protocol stack) which is assumed to be present on each node.
2s The kernel l~ s~ o~L 90l is a co--ll--u-lications network to which all DPE kernels are ~tt~he~ in order to exchange mecs~s to f~cilit~te object interaction. It is ~lefin~d in order logically to separate the colll~ g network from a L~ ~oll network which may be used for the ll~n~ sion of voice and video. The logical separation recognises that the two net vorks may have different requirements on quality of service.
The DPE servers 809 provide infrastructure support, for example in the forrn of a trader and a notification server. A trader provides a run-time 5 mech~ni~m that allows objects to locate the interfaces of other objects. A
notification server enables objects to emit notifications (for example significant events that occur during the lifetime of an object) to other objects.
Objects wishing to receive notifications register at run-time with the notification server.
Referring now to Figure 12, there is shown a hardware view of a system on which embodiments of the present invention might operate. The hardware is based around a transport network 1100 which will carry the data services provided by service providers to individual users of the system. The data transmitted across the network 1100 might include. for example. voice and/or video information. Individual users are connected to the network by different pieces of customer premises equipment (CPE) I 101, 1 102. The various parties involved in offering and carrying the net vork services~ such asservice retailers, service providers and network providers. are connected to thetransport network at a computational node 810. Each computational node 810 20 includes a variety of hardware and sofhvare features, indicated generally at 812. These include a DPE kernel 811, a protocol stack for use accordirlg to DPE principles, storage facilities 1121 and applications 1120 running at tne computational node.
The system will also include a variety of data stores 1105, 1106 25 coupled to the transport network, as shown. One of these data stores 1105 may comprise a ~n~mPnt information data store, to provide global management information in respect of services provided by the network.
It will of course be understood that with the h&-lw~ shown in Figure 12, an instance ofthe vi~ er application 18 (Figure 2) may be run at any of the individual computational nodes 810. The application will collect information from distributed objects across the network, and may report by way ofthe information screen shown in Figure 10 at the individual operator's 5 own terrnin~l.
DISTRIBUTED OBJECT SYSTEM
The present invention relates to the collection of events within a Distributed Object System.
Distributed Collly~lling is an area of co~ ulil~g in which distinct software modules running on physically separate computing nodes can communicate with each other, and can request each other to p~.rullll tasks.
The development of object-oriented technology has given Distributed Computing extra impetus in recent years~ and the convergence of the two 0 technologies has resulted in Distributed Object Technology.
As the number and complexity of these objects has increased, so have the problems involved in establishing exactly what is ha~l,e~ lg in such a system. Although a number of so~vare support tools are available to system designers and m~int~iners, they are ~;ullently rather unsatisfactory. Various 5 tools are currently available. for example. for debugging conventional "single process" software, allowing developers to step through the code in the software and to inspect the state of the program. There are also one or two tools applicable to object-orientated programming that enable prograrnmers to "visualise" objects within conventional software by showing the creation and 2 o deletion of objects.
Difficulties arise, however, since such conventional tools are really not sufficiently powerful or flexible for the needs of ~lçsi~rs and ~ ..ers of large Distributed Object Systems.
Accordillg to a first aspect of the p~ese.lt invention there is provided 2 5 a Distributed Object System having a plurality of objects, each object having an associated filter, the filter being arranged to illlerc~l m~ss~ges sent or received by its col~ ,onding object and to forward inform~tion represent~tive of said mess~g~s to an Event Collector.
The invention also extends to a corresponding method, and in particular extends, in a second aspect of the invention, to a method of characterising a Distributed Object System having a plurality of objects, the method CO~ lg providing each object with an associated filter which is arranged to intercept mesc~ges sent or received by its corresponding object and to forward information lC~.S~ ~tali~re of said messages to an Event Collector, the Distributed Object System being characterised according to the mess~Ps received by the Event Collector.
The messages collected by the Event Collector may be representative of a predefined class of events, for example the class of interactions between objects and the deletion and creation of objects. Preferably. the Event Collector may forward collected events to an Event Dispatch Mech~ni.cm which processes the events and forwards them to one or more User Applications. These User Applications may take a variety of different forrns.
including Visualizer Applications. Fault Detecting Applications. Control Applications and Charging Applications. In a preferred embodiment. several different User Applications (objects) may be running simultaneousl . and each may be independently configurable. Depending upon the particular requirem~ntc, the configuration may be automatic or user-defined.
In one forrn, the invention may provide a mech~nicm for creating a stream of events, where each event consists of either the tr~ncmicsion of a meSc~ge from one object to another, or the creation or deletion of an object.
The system may be installed without intrusive ch~nges to the code of the object th~elves. F~ll~e~more~ it may allow more than one individual to vi~ lice interactions in the system at any one time, allowing each individual to see only the actions that are relevant.
~l~f.,,~ ely, in another emborlimPnt the system may provide fault reporting and/or fault recovery services within a Distributed Object System.
The system accordingly provides a tool or series of tools which can collect information, in a well defined way. from the various objects within a Distributed Object System. The information thus collected may then be used to analyse the system, for example to find out what has happened during a s system failure or other unexpected event. Equally importantly, the information collected may be used to assist svstem ~ÇCigners who are attempting to explain the system to other people who are not directly involved in development. Conventionally, Distributed Object Systems are extremely difficult to explain, and the present invention in at least some forms, will improve the "information transfer" process from developers and designers to technical collaborators and customers.
The invention may be carried into practice in a number of ways and one specific distributed object system incorporating the invention will now be described~ by way of example. with reference to the accompanying drawings, S in which:
Figure I illustrates the Remote Procedure Call in a distributed processing environment;
Figure 2 shows and overvie-v of the svstem according to the preferred embodiment of the present invention;
Figure 3 shows the way in which filters are used to intercept mess~ges being sent and received;
Figure 4 illustrates the operation of the filters;
Figure S shows how interactions propagate between objects;
Figure 6 shows how mPsc~g~s with keys are sent between objects;
2s Figure 7 correspon(lC to Figure 6, but shows the interaction with an additional object;
Figure 8 shows how the preferred vic~-~1i7~r application registers with the event ~iCp~tf~ meçll~nicm;
Figure 9 shows the event diCp~ch mer~l~nicm forwarding information to the visualiser application;
Figure 10 shows an exemplary screen shot from the preferred vi.cll~li7~tion application;
Figure 11 shows an exemplary structure for a distributed processing environment (DPE) that may be used in association with the present invention;
and Figure 12 shows a hardware view of a platform for use with embodimPnts of the present invention.
Before describing the preferred embodiment of the present invention, it may be useful to set out some general backeround information on Distributed Processing Environments (DPEs) generally.
A large number of DPEs conform to a de-facto standard called the 5 Common Object Request Broker Architecture (CORBA). The CORBA
standard was created by the Object Management Group (OMG) which is an international consortium comprising a lar~e number of computer companies, software vendors and other interested parties.
Most DPEs use a style of interaction called the Remote Procedure Call 20 (RPC), illustrated generally in Figure 1. In the RPC model, a client object 10 sends a m~c.c~e 11 to a remote server object requesting a particular operation.
The server object 12 executes the code which corresponds to this operation, and then returns control to the client 10 by means of a reply mess~ge 13.
Typically, the outgoing mess~ge 11 CGnt~ s the name of the operation to be 2s invoked along with the arg~m~nt.~ to the operation, while the reply mec~age contains the name of the operation that was invoked along with the results of the operation.
W O 97137304 PCT/GB97tO0834 There are other interaction styles, but most may be thought of as being derived from the conventional RPC model. For exarnple, an alternative interaction style used in CORBA is the "one-way" style. In this model, the message to invoke an operation is sent to the server object, but in the me~ntime the client object cl)ntin-les to execute its own code. When the server object completes the execution of the operation concerne-l no m~occ~e is sent back. This may be viewed simply ac a conventional RPC in which there are no results, and in which no confirmation is sent back from the server object to the client object.
0 Turning now to Figure ~. there is shown an overview of the preferred embodiment of the present invention. The exemplary system is implemented by means of three main subsystems. The first subsystem 14 is an Event Collection Mech~nicm~ concerned with the collection of events which arise from the creation and deletion of objects and the interactions between them.
As may be seen from the drawing, the Event Collection Mechanism receives inforrnation from a plurality of distributed objects 2,4 which may be widely spaced within the computing environment. For example, one object may be running on one physical computer. and another on another physical computer connected to the first by a conventional local area network or even a wide area 2 o network. The second subsystem 18 takes the forrn of a Vi.cll~li7~r Application which allows users of the system to view the interactions, configure the way in which they view the interactions, and decide which interactions to view.
Several vi~ li7çr applications 18a,18b,18c may be operational at one time.
The third and final subsystem comprises an Event Dispatch Meçh~ . l6;
2s this takes the stream of events from the collection mech~ 14 and ~ ~licp~trhes it to each of the individual Vi~ li7er Applications 1 8a, 1 8b, 1 8c. It will be understood, of course, that the Event Collection Meçh~ni~m 14, the Event Dispatch Mech~ni~m 16 and the Vi~ li7~r Applications 18 may all be considered as objects in their own right.
Figure 3 shows in more detail the interactions between the individual objects and the ~vent Collection Mec~l~ni~m 14. For ease of reference, the reference numerals used for those elements corresponding to the RPC model 5 co~espond to the numerals used in Figure 1. As may be seen, the event collector 14 collects events 26.28 which are tr~n~mitted by filters 20,22 associated respectively with the client object 10 and the server object 12. The filters themselves may comprise the filters present in the CORBA conformant product Orbix. Orbix is a commercial software product available from Iona Technologies. This allows sofh~ are to be inserted ~ hich will be run during the arrival, ~licpatçh, reply and return of messages (object interactions).
Accordingly, the event collector 14 collects information relating to the tr~nsmi~sion of a message from one object to another (that is the invocation of an operation on one object by another). or the creation or deletion of an object.
15 The filters are associated with the objects in such a way that they interceptmessages being sent and received. but without requiring any changes to the objects themselves.
Figure 4 illustrates the operation of the system in practice. Figure 4a shows the situation before Object A invokes a request on Object B. Figure 4b 2 o shows the situation when the request is invoked. The outgoing message 11 is intercepted by Filter A, and a reporting message 30 is passed on to the Event Collection Merh~nicm- It will be understood, of course, that when an Object is created or ~eleted the corresponding filter will also be created or deleted, thereby enabling an event for this to be genclaled as well. The Event 2 s Collection Merh~nicm ~imlllt~neously collects events from all the active objects within the system.
All of the events collected by the Event Collection Me~ni~m 14 are then passed on, in a continllous stream, to the Event Dispatch Meçh~ni~m 16 W 097/37304 PCT/GB97tO0834 (Figure 2). Of course, collecting information on every mçss~e that passes between objects~ and on the creation and deletion of every object, is likely to result in information overload. Typically, the user may be interested only in what is happening to particular objects, or to particular classes of objects, and 5 it would therefore be useful to provide some method of establishing which events are of interest. The way in which this is achieved will now be described.
It should first be noted that in a Distributed Object System, when an object in the system interacts with another, further "knock-on" interactions 10 may well ensue. This is illustrated in Figure 5, in which an interaction between objects 32,34 has created "knock-on" interactions with further objects 36,38. In the l)re~-lcd embo~ t a mech~ni~m is provided whereby the subsequent "knock-on" interactions may be linked back to the original interaction which triggered them off.
The wa- in which this is achieved may be seen with reference to Figure 6. Each object in the system is given the unique key or identifier, this key beine stored in association with the respective filter. Then. if an object (say Object A) calls on the services of another object (Object B), the key of Object A is prop~g~tecl to Object B which takes on this key until it has finished 2 o servicing the request of Object A. It then discards the key of Object A. and returns to its own key again.
Figure 6a illustrates the situation prior to Object A invoking a request on Object B. As will be seen, the filter 20 associated with Object A contains a unique Key A, and the filter 22 ~csoci~ted with the Object B cont~inc a unique 2 5 Key B.
Figure 6b shows the situation as Object A invokes a request on Object B. An outgoing mecc~ge 11 is passed between Object A and Obiect B, this message being i~llerc~,pted as previously described by the filter 20 which WO 97/37304 PCTtGB97/00834 generates a reporting message 30. The filter 20 attaches to the message 11 its own key, Key A, and that is passed on to the receiving filter 22. which currently contains Key B. When the mess~ge cont7~inin~ Key A arrives, the filter 22 takes on Key A in replacement for its original key, and passes the rest 5 of the message on to Object B.
Figure 6c shows the situation while the request is being serviced by Object B. As will be seen, Object B's filter 22 has now taken on Key A.
Figure 6d shows what happens when Object B completes the request, and sends back a reply message to Object A. As the mçcs~ge is sent, Object 0 B's filter 22 takes back on its original key. Kev B. The reply message is received by the filter 20, and passed on to Object A. Simlllt~neously. the filter 20 generates a further reporting message 30'.
which is passed on to the Event Collection Mech~ni~nl 14 (Figure 2~.
Thus, all of the events which occur as a result of the initial interaction 5 sent from Object A to Object B can be associated via Key A with Object A.
The Event Collection Mec~nicm understands that all of the reported events emanate from Object A, since both of the reporting messages 30.30' include within them Key A.
A slightly more complex scenario mav be seen in Figure 7, where 2 o Object B in turn invokes the services of a third object. Object C.
Figure 7a shows the situation before Object A invokes a request on Object B.
Figure 7b shows the situation during the invoking of the request. A
reporting mPss~e 44, incl~ ing Key A, is sent to the Event Collection 2 5 Mecll~ni~m inforrning it of the invoking request.
Figure 7c shows the situation dunng the time that Object B is servicing the request of Object A. It will be noted that the filter 22 of Object B has taken on Key A.
W 097/37304 PCTtGB97/00834 Figure 7d now shows what happens when, prior to control returning to Object A, Object B needs to invoke a request on another object 40 (Object C).
Object C has associated with it its own filter 42 which at this point contains Key C. The filter 22 intercepts the message and appends to it its own key s which is currently Key A. It also provides a further reporting mec~ge 46 to the Event Collection Mecl-~ni~m, which itself contains Key A indicating that the initial interaction em~n~te~ from Object A.
Figure 7e shows the situation during the time that Object C is servicing the request from Object B. Object B's filter 22 contains Key A. as does now Object C's filter 42.
Figure 7f illustrates the sending of the reply back from Object C to Object B. Once the reply has been sent. the filter ~2 dispenses with Key A
and reverts to its original key, Ke- C. The filter 22 intercepts the reply message and sends out another reporting message 4~ to the Event Collection 15 Mech~ni.~m Again, this contains Key A since it em~n~tes from the filter 22 which currently contains that particular key.
Finally, Figure 7g shows what happens when Object B completes its request, and returns control back to Object A. The repl- message is sent back from Object B to Object A, and Object B's filter 22 takes on again its original 2 o key, Key B. On receipt of the reply message, Object A's filter 20 sends out yet another m-oss~e 50 to the Event Collection Mech~ni.cm. Once again. this message will contain the Key A, since that is the key currently associated with the filter 20.
It will be seen, thele~ e, that the key is propagated from one object to 2 s the next, by adding it to the m~ss~ge at the sçn(ting filter, and removing it from the mess~ge at the receiving filter.
Using this meçll~ni.~m, it is now possible to select particular events or classes of events for filrther analysis. For example, if a user of the system wished to vi.cu~lice the whole sequence of events which had occurred as a result of an interaction emitted from Object A. all he would need to do would be to select only those events having associated with them the relevant key, namely Key A.
Further details will now be given, with reference to Figures 8 and 9, on the Event Dispatch Mech~nicrn and its connection with the Visualizer Application.
As events are collected by the Event Collection Mer~l~nicm, they are forwarded to the Event Dispatch Mechanism 16. The Event Dispatch 0 Mech~nicm receives details of all events collected by the Event Collection Mech~ni.cm 14. and is arranged to forvard those particular events that the user is interested in to the Visualizer Application 18.
As may be seen in Figure ~, the Event Dispatch Mechanism 16 incorporates within it an object, kno~vn as the Event Di.cp~tcher Factory 52.
responsible for creating fi~rther objects 54 knoun as Event Dispatchers. Each Event Dispatcher is responsible for sendin~ events to a particular Visualizer Application. A user who wishes to ~ iew a particular subset of events runs the Visualizer Application Object 18, which then re~isters as indicated by numeral 56 with the Event Dispatch Mech~nicm 16.
As indicated in Figure 9, several individual instances (objects) of the Vin~li7Pr Application 18 may in practice be running at once, each of which has registered with the Event Dicp~tch Mech~nicm 16. On each registration, the Event Dispatcher Factory 52 creates a new Event Dispatcher Object 54 which passes information as indicated at 58 to its corresponding Vic-1~li7Pr Application. Each Vic~ r Application 18 may be configured di~elllly, and may require information on a different subset of the events which have been collected (or are being collected) by the Event Collection Mech~rli.cm 14.
The necess~. y filtering is carried out by the respective Event Dicp~tch~.r 54 WO 97~7304 PCT/GB97/00834 which passes on only that information which has been requested by its individual Vicl-~li7er Application.
The Vi~ i7er Application 18 may take many forms, having a variety of ~ont-ends, the preferred version being illustrated schematically in Figure 10. The user of the Visualizer Application sees information displayed graphically within a large window 60. Within a ~vorkspace 62 of the window are displayed the various objects that the Visualizer Application has been configured to show. Typically, the display will show a plurality of object icons 64, connected by arrows 66. Each icon 64 represents a particular object, with the arrows representing interactions between the objects. Certain ofthe arrows 67 and/or the object icons 68 may be displaved in a different colour to indicate the active (current) interaction and/or object. In the preferred display, the most recentlv displayed interaction is shown in red; as another event arrives, that becomes the active interaction and the previous actiYe interactionbecomes grey.
The windo-v 60 may further include a tool bar 70 having a status display 7~ and a pluralitv of buttons 74 whereby the user may configure the display to his or her requirements.
The preferred capabilities of the Vicll~li7er Application are set out 2 o below:
Configurable modes:
(a) Step mode - in this mode, events are stored in a queue at the application, and a counter on the application shows how many events are currently queued. A step button allows the user to 2s move sequPnti~lly through the stored events, displaying one for each click of the step button;
(b) Run mode - in this mode the application does not queue the interactions that arrive, but attempts to display them irnrnediately. There is a control which allows the user to pause the display of events, in which case they are temporarily stored in the queue until the play button is pressed. The application imposes a minitnl~m time between the display of events which is configurable by the user.
Live or recorded event streams:
(a) In live mode, events are received from the event collection and dispatch systems as described above;
(b) in play from file. a sequence of events is fed from a stored file;
0 (c) In record to file. a live sequence of events id displayed~ and at the same time, recorded into a file for playback at a later date.
Configuration of display:
The Visualizer Application can be configured bv loading in a configuration file which contains information about:
(a) Objects - the configuration file allows the user to configure which objects are to be displayed~ what position they are to be displayed in, what colour should be used for the object, and what category of display behaviour it should conform to;
(b) Events - the configuration file also allows the user to configure which incoming events are to be displayed, and what user-friendly narne should be displayed by each event.
Configuration of key:
This allows the user to receive events which occur as a result of actions taken by an object (or set of objects) which has been configured with a certain 2~ key.
Interactions are displayed on the screen only if all four of the following criteria are met:
(a) Interactions must have the same key as that which was configured into the Visualizer Applications (unless no key has been configured);
(b) Interactions must originate from an object which has been configured to be of interest;
5 (c) Interactions must terrninate at an object which has been configured to be of il.t~,le~l.
(d) Interactions must have a mess~ge name which has been configured to be of interest.
As mentioned above, objects may be configured to conforrn to certain behaviours. The following behaviour t,vpes are exemplary, and additional tvpes may be added at any time by modifying the Visualizer Application:
Type 1 object - This type of object is always visible on the screen of the Visualizer Application.
Type 2 object - This type of object becomes visible when an event is received that tells the Visualizer Application that the object has been created. and becomes hidden when an event arrives that corresponds to the deletion of the object.
Type 3 object - This type of object becomes visible when an interaction is displayed that goes to the object, but is hidden by the arrival of a deletion event.
In other embodiments (not shown) the Vi~ 1i7~r Application 18 may be replaced by other objects that can make use of the information collected by the Event Collection Mecll~ni~m. For example, a Fault-Reporting 2 5 Application could provide for fault-monitoring of a Distributed Object System.
Such an application might include the production of system alarms where une,~,e~led events have occurred, along with error-recovery objects designed to modify the operation of the system in the event of an alarm. The system could, for instance, be closed down entirely automatically in applopliate circumstances, or other fault-recovery objects could be run. The system of the present invention may therefore be useful not only to system designers and ~n~ins,~iners, but also as a means of monitoring an Operational Distributed s Object System.
In yet a further embodiment (not shown) the Vi~ i7~r Application may be replaced with a Charging Application. The events collected by the Event Collection Mech~ni~m may then be used to charge for the use of objects or services.
Reference will now be made to Figure l l. which illustrates the infrastructure aspects of the engineering model defining the preferred Distributed Proces~in~ EnvironmPnt (DPE). The DPE is an infrastructure (of a type known per se) that supports the interactions of the various objects previously ~iscl~csed The purpose of the DPE is, amongst other things, to 15 shield the application programs from the heterogeneous and distributed natureof the underlying environment, and to provide a mech~ni~m that allows objects to interact without a knowledge of the details of the particular computing node they are active on. The DPE defines four types of entity: a DPE kernel 8 l l, a kemel transport network 90l, DPE stubs. and DPE servers 809. The kernel 20 transport network 90l is linked as shown in the Figure with a plurality of interlinked computing nodes 8 l0.
The DPE kernel defines a core set of communications, storage and processin~ capabilities (for e~..~;le a protocol stack) which is assumed to be present on each node.
2s The kernel l~ s~ o~L 90l is a co--ll--u-lications network to which all DPE kernels are ~tt~he~ in order to exchange mecs~s to f~cilit~te object interaction. It is ~lefin~d in order logically to separate the colll~ g network from a L~ ~oll network which may be used for the ll~n~ sion of voice and video. The logical separation recognises that the two net vorks may have different requirements on quality of service.
The DPE servers 809 provide infrastructure support, for example in the forrn of a trader and a notification server. A trader provides a run-time 5 mech~ni~m that allows objects to locate the interfaces of other objects. A
notification server enables objects to emit notifications (for example significant events that occur during the lifetime of an object) to other objects.
Objects wishing to receive notifications register at run-time with the notification server.
Referring now to Figure 12, there is shown a hardware view of a system on which embodiments of the present invention might operate. The hardware is based around a transport network 1100 which will carry the data services provided by service providers to individual users of the system. The data transmitted across the network 1100 might include. for example. voice and/or video information. Individual users are connected to the network by different pieces of customer premises equipment (CPE) I 101, 1 102. The various parties involved in offering and carrying the net vork services~ such asservice retailers, service providers and network providers. are connected to thetransport network at a computational node 810. Each computational node 810 20 includes a variety of hardware and sofhvare features, indicated generally at 812. These include a DPE kernel 811, a protocol stack for use accordirlg to DPE principles, storage facilities 1121 and applications 1120 running at tne computational node.
The system will also include a variety of data stores 1105, 1106 25 coupled to the transport network, as shown. One of these data stores 1105 may comprise a ~n~mPnt information data store, to provide global management information in respect of services provided by the network.
It will of course be understood that with the h&-lw~ shown in Figure 12, an instance ofthe vi~ er application 18 (Figure 2) may be run at any of the individual computational nodes 810. The application will collect information from distributed objects across the network, and may report by way ofthe information screen shown in Figure 10 at the individual operator's 5 own terrnin~l.
Claims (18)
1. A system for visualizing objects within a distributed object system, the system having a plurality of objects, each object having an associated filter arranged to intercept messages sent or received by its corresponding object and to forward information representative of said messages to an event collector;
and a visualizer application arranged to receive the said information and having a graphical front-end for displaying to a user a graphical representation of the distributed object system, the visualizer application being user -configurable to display a selected category of objects within the system.
and a visualizer application arranged to receive the said information and having a graphical front-end for displaying to a user a graphical representation of the distributed object system, the visualizer application being user -configurable to display a selected category of objects within the system.
2. A system as claimed in Claim 1 in which the filter is further arranged to forward information to the event collector on the creation or deletion of a corresponding object.
3. A system as claimed in Claim 1 or Claim 2 in which each client object has an associated client filter, the client filter having a client key which is representative of the client object.
4. A system as claimed in Claim 3 in which when the client object sends an outgoing message to a server object invoking the server object, the client filter forwards information representative of the client key to the event collector.
5. A system as claimed in Claim 3 in which when the client object sends an outgoing message to a server object invoking the server object, the client filter adds to the outgoing message information representative of the client key.
6. A system as claimed in Claim 5 in which the outgoing message is received by a server filter associated with the server object, the server filter being arranged to replace the server key with the client key on receipt of the outgoing message.
7. A system as claimed in Claim 6 in which when the server object sends a reply message to the client object returning control to the client object, the server filter replaces the client key with the server key.
8. A system as claimed in Claim 7 in which the reply message is received by the client filter, the client filter being arranged to forward further information representative of the client key to the event collector.
9. A system as claimed in any one of Claims 1 to 8 in which the plurality of objects are themselves arranged to interact as the distributed object system, independently of the filters; the filters being associated with, but not altering any code of, the objects.
10. A system as claimed in Claim 1 in which the information forwarded to the event collector includes information identifying a base object, the base object being the first instigator of an outgoing server-invoking message which has ultimately resulted in the said intercepted message.
11. A system as claimed in Claim 1 in which the filter is CORBA-compliant.
12. A system as claimed in any one of claims 1 to 11 in which events collected by the event collector are processed by an event dispatch mechanism and are forwarded to the visualizer application.
13. A distributed object system as claimed in Claim 12 in which the event dispatch mechanism is arranged to forward to the visualizer application only events of interest to the user.
14. A distributed object system as claimed in Claim 12 or Claim 13 in which the event collector is arranged to forward processed events to a plurality of visualizer applications.
15. A distributed object system as claimed in Claim 14 in which the separate visualizer applications are concurrently-running objects.
16. A distributed object system as claimed in any one of Claims 12 to 15 in which the or each visualizer application is arranged to register with the event dispatch mechanism.
17. A distributed object system as claimed in Claim 16 in which an event dispatcher factory of the event dispatcher mechanism is arranged to create an event dispatcher for each registration of the visualizer application with the event dispatcher mechanism, the event dispatcher being arranged to forward events to its respective visualizer application based on a configuration of the said respective visualizer application.
18. A method of visualizing a distributed object system having a plurality of objects, the method comprising providing each object with an associated filter which is arranged to intercept messages sent or received by its corresponding object and to forward information representative of said messages to an event collector, the distributed object system being visualized graphically by a user-configurable visualizes application arranged to display a user-selected category of objects within the system, based on said information received from the event collector.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GBGB9606733.5A GB9606733D0 (en) | 1996-03-29 | 1996-03-29 | Collection of events within a distributed object system |
| GB9606733.5 | 1996-03-29 | ||
| PCT/GB1997/000834 WO1997037304A1 (en) | 1996-03-29 | 1997-03-25 | Collection of events within a distributed object system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2248096A1 CA2248096A1 (en) | 1997-10-09 |
| CA2248096C true CA2248096C (en) | 2003-02-18 |
Family
ID=10791327
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002248096A Expired - Fee Related CA2248096C (en) | 1996-03-29 | 1997-03-25 | Collection of events within a distributed object system |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US6658487B1 (en) |
| EP (1) | EP0891584B1 (en) |
| JP (1) | JP2000507724A (en) |
| CN (1) | CN1220018A (en) |
| AU (1) | AU712616B2 (en) |
| CA (1) | CA2248096C (en) |
| DE (1) | DE69705507D1 (en) |
| GB (1) | GB9606733D0 (en) |
| WO (1) | WO1997037304A1 (en) |
Families Citing this family (28)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6684246B1 (en) * | 1999-02-03 | 2004-01-27 | William H. Gates, III | Method and system for tracking clients |
| US6782541B1 (en) * | 1999-05-28 | 2004-08-24 | Avaya Technology Corp. | System and method of exchanging information between software modules |
| WO2001084302A2 (en) * | 2000-05-02 | 2001-11-08 | Sun Microsystems, Inc. | Event service method and system |
| US20030028589A1 (en) * | 2001-02-23 | 2003-02-06 | Hittleman Ken D. | System and method to transfer an application to a destination server module in a predetermined storage format |
| US20020124029A1 (en) * | 2001-03-02 | 2002-09-05 | Gwinn John Glen | Method and apparatus for creating, embedding and using a searchable font |
| DE10118502C1 (en) | 2001-04-12 | 2002-08-08 | Siemens Ag | Process for the acquisition and recording of system information and processes in distributed concurrent component-based software systems |
| US8291434B1 (en) * | 2001-06-13 | 2012-10-16 | Digi International Inc. | Computer system and method to dispatch and receive a message responsive to the occurrence of an event |
| US7152204B2 (en) * | 2001-10-18 | 2006-12-19 | Bea Systems, Inc. | System and method utilizing an interface component to query a document |
| US6931405B2 (en) * | 2002-04-15 | 2005-08-16 | Microsoft Corporation | Flexible subscription-based event notification |
| US7937344B2 (en) | 2005-07-25 | 2011-05-03 | Splunk Inc. | Machine data web |
| JP2007048023A (en) * | 2005-08-10 | 2007-02-22 | Hitachi Software Eng Co Ltd | Composite interface indicator light and notification system using indicator light |
| WO2008043082A2 (en) | 2006-10-05 | 2008-04-10 | Splunk Inc. | Time series search engine |
| US8015571B2 (en) * | 2007-03-16 | 2011-09-06 | Google Inc. | Registering an event |
| US11182175B2 (en) * | 2008-09-18 | 2021-11-23 | International Business Machines Corporation | Apparatus and methods for workflow capture and display |
| US8786702B2 (en) * | 2009-08-31 | 2014-07-22 | Behavioral Recognition Systems, Inc. | Visualizing and updating long-term memory percepts in a video surveillance system |
| CN102387169B (en) | 2010-08-26 | 2014-07-23 | 阿里巴巴集团控股有限公司 | Delete method, system and delete server for distributed cache objects |
| US20130091266A1 (en) | 2011-10-05 | 2013-04-11 | Ajit Bhave | System for organizing and fast searching of massive amounts of data |
| US10614132B2 (en) | 2013-04-30 | 2020-04-07 | Splunk Inc. | GUI-triggered processing of performance data and log data from an information technology environment |
| US10353957B2 (en) | 2013-04-30 | 2019-07-16 | Splunk Inc. | Processing of performance data and raw log data from an information technology environment |
| US10346357B2 (en) | 2013-04-30 | 2019-07-09 | Splunk Inc. | Processing of performance data and structure data from an information technology environment |
| US10019496B2 (en) | 2013-04-30 | 2018-07-10 | Splunk Inc. | Processing of performance data and log data from an information technology environment by using diverse data stores |
| US10318541B2 (en) | 2013-04-30 | 2019-06-11 | Splunk Inc. | Correlating log data with performance measurements having a specified relationship to a threshold value |
| US10997191B2 (en) | 2013-04-30 | 2021-05-04 | Splunk Inc. | Query-triggered processing of performance data and log data from an information technology environment |
| US10225136B2 (en) | 2013-04-30 | 2019-03-05 | Splunk Inc. | Processing of log data and performance data obtained via an application programming interface (API) |
| US9363149B1 (en) | 2015-08-01 | 2016-06-07 | Splunk Inc. | Management console for network security investigations |
| US9516052B1 (en) | 2015-08-01 | 2016-12-06 | Splunk Inc. | Timeline displays of network security investigation events |
| US10254934B2 (en) | 2015-08-01 | 2019-04-09 | Splunk Inc. | Network security investigation workflow logging |
| US10440054B2 (en) * | 2015-09-25 | 2019-10-08 | Perspecta Labs Inc. | Customized information networks for deception and attack mitigation |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1059981A (en) * | 1988-12-30 | 1992-04-01 | 惠普公司 | Manage the encapsulation of the application program of facility environment for holding into a pair of orthicon |
| US5822527A (en) * | 1990-05-04 | 1998-10-13 | Digital Equipment Corporation | Method and apparatus for information stream filtration using tagged information access and action registration |
| DE69029515D1 (en) * | 1990-06-28 | 1997-02-06 | Ibm | Message processing in a data processing device |
| CA2118169A1 (en) * | 1993-10-27 | 1995-04-28 | Michael R.C. Seaman | Event architecture for system management in an operating system |
| US5734903A (en) * | 1994-05-13 | 1998-03-31 | Apple Computer, Inc. | System and method for object oriented message filtering |
| US5774669A (en) * | 1995-07-28 | 1998-06-30 | The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration | Scalable hierarchical network management system for displaying network information in three dimensions |
-
1996
- 1996-03-29 GB GBGB9606733.5A patent/GB9606733D0/en active Pending
-
1997
- 1997-03-25 EP EP97914434A patent/EP0891584B1/en not_active Expired - Lifetime
- 1997-03-25 AU AU21681/97A patent/AU712616B2/en not_active Ceased
- 1997-03-25 WO PCT/GB1997/000834 patent/WO1997037304A1/en active IP Right Grant
- 1997-03-25 CN CN97195059A patent/CN1220018A/en active Pending
- 1997-03-25 US US09/043,147 patent/US6658487B1/en not_active Expired - Lifetime
- 1997-03-25 JP JP9535014A patent/JP2000507724A/en not_active Ceased
- 1997-03-25 DE DE69705507T patent/DE69705507D1/en not_active Expired - Lifetime
- 1997-03-25 CA CA002248096A patent/CA2248096C/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| AU2168197A (en) | 1997-10-22 |
| EP0891584B1 (en) | 2001-07-04 |
| JP2000507724A (en) | 2000-06-20 |
| CN1220018A (en) | 1999-06-16 |
| WO1997037304A1 (en) | 1997-10-09 |
| CA2248096A1 (en) | 1997-10-09 |
| GB9606733D0 (en) | 1996-06-05 |
| US6658487B1 (en) | 2003-12-02 |
| DE69705507D1 (en) | 2001-08-09 |
| AU712616B2 (en) | 1999-11-11 |
| EP0891584A1 (en) | 1999-01-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2248096C (en) | Collection of events within a distributed object system | |
| US6356282B2 (en) | Alarm manager system for distributed network management system | |
| US7200651B1 (en) | Dynamic configuration and up-dating of integrated distributed applications | |
| EP0737921B1 (en) | System and method for modelling a computer network | |
| US5261044A (en) | Network management system using multifunction icons for information display | |
| US6373383B1 (en) | Method and apparatus for policy-based alarm notification in a distributed network management environment | |
| US6255943B1 (en) | Method and apparatus for distributed object filtering | |
| US5295244A (en) | Network management system using interconnected hierarchies to represent different network dimensions in multiple display views | |
| US6526442B1 (en) | Programmable operational system for managing devices participating in a network | |
| JP3489726B2 (en) | How to manage network elements | |
| US5751933A (en) | System for determining the status of an entity in a computer network | |
| US7693974B2 (en) | System and method for providing a graphical user interface to, for building, and/or for monitoring a telecommunication network | |
| WO1996031035A1 (en) | Method and apparatus for policy-based alarm notification in a distributed network management environment | |
| JP2000181756A (en) | Method and device for state display | |
| Brunner et al. | Management of Active Networks | |
| de la Fuente et al. | Application of TINA-C architecture to management services | |
| AU720061C (en) | Method and apparatus for policy-based alarm notification in a distributed network management environment | |
| Richardson et al. | SMT: A System Monitoring Tool for DCE | |
| Lumpp et al. | Xunify-a performance debugger for a distributed shared memory system | |
| Andrade et al. | Towards service management with the SIS distributed platform |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |