WO2003030481A2 - Verfahren, vorrichtung und speichermedium mit software zum anzeigen von eigenschaften eines objektes einer server-software in einem client-rechner - Google Patents

Verfahren, vorrichtung und speichermedium mit software zum anzeigen von eigenschaften eines objektes einer server-software in einem client-rechner Download PDF

Info

Publication number
WO2003030481A2
WO2003030481A2 PCT/DE2002/003648 DE0203648W WO03030481A2 WO 2003030481 A2 WO2003030481 A2 WO 2003030481A2 DE 0203648 W DE0203648 W DE 0203648W WO 03030481 A2 WO03030481 A2 WO 03030481A2
Authority
WO
WIPO (PCT)
Prior art keywords
properties
server
computer
client
client computer
Prior art date
Application number
PCT/DE2002/003648
Other languages
English (en)
French (fr)
Other versions
WO2003030481A3 (de
Inventor
Peter Hofmann
Wolfgang Kammhuber
Thomas Strauss
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to AU2002339329A priority Critical patent/AU2002339329A1/en
Publication of WO2003030481A2 publication Critical patent/WO2003030481A2/de
Publication of WO2003030481A3 publication Critical patent/WO2003030481A3/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0233—Object-oriented techniques, for representation of network management data, e.g. common object request broker architecture [CORBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/22—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/75—Indicating network or usage conditions on the user display
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0246—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols
    • H04L41/0253—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols using browsers or web-pages for accessing management information

Definitions

  • the invention relates to a method, a client computer, a server computer and a storage medium with appropriate software for displaying properties of an object of a server software in a client computer and preferably the treatment of tabular ob ect list windows in network management systems.
  • the central administration of heterogeneous networks becomes more and more complex with an increasing number of services and interfaces to be managed.
  • An essential aspect here is the administration of the physical and logical connections in a heterogeneous network.
  • a large number of connections must be managed even for a single computer in a network.
  • the computer can be physically connected to the network and a large number of further subunits, such as a local printer or hard disk.
  • a large number of logical connections from the computer to other computers in the network, the Internet or other networks can exist in parallel.
  • objects serve as program-related
  • connection data are then managed as attributes of the objects.
  • object Connection! can be created, which contains the attributes Computer, Computer2 and Connection Type.
  • the data available in the software for managing the connections must, for example, be one
  • Administrator of the network can be made available so that he can monitor or adjust the data.
  • the data is made available by a server for a large number of end devices as clients.
  • GUI graphical user interface
  • FIG. 6 An example of a window displayed on a client screen as a graphical user interface is shown in FIG. 6. The corresponding procedure between
  • the server and client for displaying the data are shown in FIG. 7 with their essential steps and message flows.
  • a selection field 62 for filter methods and an input field for filter parameters 63 are shown in FIG. 6 under a title line 61 of the window.
  • the window also includes a list for attributes 64 to 66, which are displayed in fields 67 to 69 for objects of an object type.
  • the filters serve to limit or sort the amount of data to be displayed.
  • the message flow diagram in FIG. 7 shows a server 70 and a client 80.
  • a user selects an object type in a step 71 and then the window from FIG. 6 is displayed.
  • step 72 the user is shown the filter methods known for the object type, which are permanently programmed in the graphical user interface, and associated filter parameters for selection.
  • the client 80 sends a request 81 for a filtered object list to the server 70.
  • objects are filtered in accordance with the requested filter method F1 and the requested filter parameters FPl , As a result, a list of objects is obtained which are known for the object type in the server software. This list is sent to the client 80 with a message 82.
  • the user selects one of the objects displayed to him in a step 74 and requests the properties of the selected object with a message 83.
  • the client receives the attributes AI to A3 for one or more objects. Finally, he displays these in a step 75, for example in fields 67 to 69 of FIG. 6.
  • the properties displayed to the user in the form of the offered filter methods, filter parameters and attributes to be displayed, are permanently programmed into the program code of the window from FIG. 6.
  • Another object type is often added on the server side or the selection of the properties of an object type that a server wants to offer to the client changes.
  • a new window is programmed for the client software or the programming of the existing windows is adapted.
  • the entire client software for displaying the windows must then be re-translated and linked.
  • connection management system it is therefore necessary to have the client software or its GUI in all clients of the connection management system.
  • the object of the present invention is to provide a method, a client computer, a server computer and storage media with corresponding software for displaying properties of objects stored on the server side in a client computer, which change the type or number of properties of an object in enable the server software regardless of a corresponding change in the client software.
  • One aspect of the present invention is the display of properties for objects of different types in a single flexible window in a client computer.
  • the objects are examined in a server computer for their properties defined for them. Examination of defined properties is made possible in particular by observing a corresponding naming convention for classes and their methods in the server computer. Both an instance of the classes and the class itself can be seen as an object. Compliance with a corresponding Such an inheritance hierarchy for the classes and objects of the server software can support such a procedure.
  • a method for displaying properties of objects of a server software on a display device of a client computer comprises the following steps: sending request data for the properties of a Object of the server software from the client computer to the server computer, determining the properties requested in the server computer, sending the determined properties from the server computer to the client computer, displaying the properties sent on the display device of the client Calculator, the step of determining the
  • Properties uses a predetermined naming convention, which is used for methods of objects of the server software, in order to recognize the methods defined for the object by the method name, and determines the properties by means of the recognized methods.
  • Properties of objects which can also have a structure unknown to the client, can thus be displayed in a graphical user interface on the client computer.
  • a graphical user interface on the client computer.
  • the requested properties are determined in the step of determining as return values of a call to the recognized methods.
  • Methods that provide properties as return values of their calls are often already available. Then only these methods have to be followed in the server software of the predetermined naming convention in order to achieve the desired flexibility.
  • a central function in the server software can carry out the step of determining for all object types, which saves further coding effort.
  • the requested properties are determined from the method names of the recognized methods in the step of determining.
  • information about the methods defined for the object can thus be displayed as properties of the object.
  • further information can also be contained in the method name by means of a correspondingly adapted naming convention.
  • Filters that are defined for the object are preferably requested in the step of sending request data, the recognized methods being filter methods in the step of determining.
  • a user can thus be provided with filters on the display device of the client computer, regardless of the object type, which can, for example, restrict or select objects whose properties are to be displayed in a further step.
  • Filter method names the defined filters and one for each Filter variable number or type of parameters can be determined.
  • additional information on the properties of the object is also determined in the step of determining.
  • the step of displaying the properties of the object can thus be flexibly adapted in accordance with the additional information or the properties of the object can be prepared in a manner corresponding to the additional information.
  • Additional information can be determined, for example, the name of a property to be displayed, filter parameters can be determined or properties, such as references to other objects or properties to be replaced depending on the language, can be managed accordingly.
  • the recognized methods are interface methods for the properties of the object, which include the names of the properties as additional information in their method name.
  • the name of the property can thus be derived from the method name and used as additional information.
  • Objects that represent an object class are preferably stored in the server software at runtime of the server software, wherein instances of the object class can be generated and stored at runtime of the server software, or objects that are an instance of an object class are stored. It is also possible to use a first group of objects, to which a large number of objects can be assigned. In the case of such assigned or derived objects, multi-stage methods are conceivable to first determine the objects defined for an object and then to display the properties of the determined objects.
  • the step of sending request data further comprises the steps of sending a list request, which requests a list of objects according to a first filter, from the client computer to the server computer and sending the one based on the first Filters in the server determined list of objects from the server computer to the client computer and a display of the list of objects in the client computer for a possible selection of the object from the list of objects.
  • the step of sending request data further comprises the steps of sending a filter request from the client computer to the server computer, evaluating the filter request in the server computer, the filter methods defined for the object using a predetermined name portion in the name of filter methods are determined, sending the determined filter from the server computer to the client computer and displaying the received filter in the client computer for selecting a second filter from the received filters.
  • the second filter is preferably the aforementioned first filter.
  • a client computer and / or a
  • Server computer can be adapted or contain means to carry out the corresponding steps of the described method in a client-server system.
  • a storage medium can contain an executable command sequence or client or server software, which is adapted on a client or server computer to carry out corresponding steps of the described method.
  • Figure 1 is a schematic representation of a client-server system according to the invention.
  • Fig. 2 is a schematic representation of the units of a
  • FIG. 3 shows a schematic illustration of a simple inheritance hierarchy for object classes
  • FIG. 4 is an illustration of a graphical user interface in accordance with the invention.
  • FIG. 6 shows a representation of a user interface according to the prior art
  • FIG. 7 shows a message flow diagram for a method in a client-server system according to the prior art.
  • FIG. 1 shows a client-server system with a server 10, which includes server software 11 and an optional database 12. There is an object 13 to 15 in the server software 11 shown.
  • the server computer 10 is connected to a plurality of client computers 20a to 20c, each of which has client software 21a to 21c.
  • the client software 21a to 21c shows a graphical user interface for a user, not shown, on a display device 22a to 22c of the client computer 20a to 20c, which serves to visualize properties of the objects 13 to 15 stored on the server side.
  • the object 13 to 15 is an object of a plurality of objects, not shown, in the server software 11.
  • its internal structure is shown in FIG. 1.
  • it comprises a first interface 14, for providing the properties of the object or its instances, and a second interface 15, which, for example, provides functions for generating instances of the object or its filtering methods.
  • server software can only be a component of the software running on the server 10.
  • Fig. 2 shows a schematic representation of the essential units of a computer.
  • a server computer will usually include a CPU 23, a memory 24 for persistent data storage, for example of the server software, a working memory 25 and an external interface 28 for connecting the server computer to the client-server system, for example via a network.
  • Properties of objects of the server software can be temporary in the working memory 25 or persistent in the memory 24 be saved. However, the properties can also be stored in a separate database, which can be connected to the server computer via the external interface 28 or via an optional internal interface 29.
  • the server computer optionally includes an input unit 26 and an output unit 27, which can be used, for example, for administration of the server software.
  • a client computer becomes at least one CPU 23, one
  • Work memory 25 an output unit 27, preferably a display device, and the external interface 28.
  • the client computer is connected to the client-server system via the external interface 28, for example via the network.
  • the client server expediently comprises a memory 24 for the persistent storage of the client software, which receives data from a server via an external interface 28 which comprise the properties of objects.
  • the client computer further includes an input unit 26 to enable user input, for example, in response to displayed data.
  • Input units 26 can have a large number of subunits, such as a keyboard, mouse, microphone or touch-sensitive screens. Also,
  • Output units 27 may include a variety of sub-units, such as monitors, speakers, and printers.
  • Class B0 to B32 are usually used derived from each other.
  • Class B21 is derived from class B1, which in turn was derived from class BO.
  • a class is a structure defined by the corresponding program code, for example in the
  • Methods and attributes can be defined in a class.
  • the attributes have an attribute name and an attribute value, which can be understood as a data field or content of the attribute.
  • Methods are executable program structures that process data and can also be called callable methods or functions. You can process an optional input value and deliver an optional return value as a result.
  • a class is clearly identified by its name, which is also known as the base name.
  • a class is represented by an object at runtime of the server software. Instances of a class can be created as additional objects.
  • the server software therefore has a large number of objects, which can be both classes and instances of the classes. Both attributes and methods are defined for the objects, both of which are referred to as properties of the objects.
  • the computer from FIG. 2 could be represented in the server software by an object Computer1, which is an instance of the class Hardware_Computer, which in turn is derived from the class Hardware.
  • object Computer1 which is an instance of the class Hardware_Computer, which in turn is derived from the class Hardware.
  • the units 23 to 29 can act as objects Obj23 to Obj29
  • Server software also properties of other units from the network it manages. This example turns out For reasons of transparency, they are not taken into account.
  • the structuring of the objects 13 to 15 in the server software 11 in FIG. 1 already indicates a possible implementation of the server objects by Enterprice Java Beans (EJB).
  • EJB Enterprice Java Beans
  • session beans which essentially store temporary data
  • entity beans the properties of which are stored persistently.
  • Objects 13 to 15 represent an entity bean. It consists of a home interface 15, which includes methods for creating or destroying instances of the entity bean ("create” or “delete”) and the corresponding filter methods ("find”) , a remote interface 14, which contains the interface methods ("get” and “set”) for providing the properties of the object, and the actual core function 13 or bean. Following a simple naming convention, the three corresponding classes are called " ⁇ base name> Home”, “ ⁇ base name> Remote” and " ⁇ base name> Bean”.
  • the home interface 15 can also provide a method for recognizing individual objects or instances of the entity bean.
  • the name or the existence of the entity bean can be known to the client via an additional component, not shown, such as the "Java Name Directory Interface" (JNDI).
  • JNDI Java Name Directory Interface
  • FIG. 4 shows a window with a list of objects and their properties, as is the case with a graphic User interface of a client software is displayed in a client computer on its screen or output unit.
  • a selection field 42 for a base name representing a name of an object class In addition to a title bar 41 of the list window, a selection field 42 for a base name representing a name of an object class, a selection field 43 for a filter method and an input field 44 for optional filter parameters are shown.
  • a list of attributes or properties with two columns attribute name 47 and attribute value 49 with corresponding fields 48 and 50 is displayed.
  • the number of lines in the list of objects 45 and the list of attributes 47, 49 are variable.
  • hardware_ subunit is entered by the user as the base name or selected from a list of base names. Then the filter methods defined for the object of this class (findLwby_Name, findLwby__Interfaces, ...) are offered for selection in field 43. After selecting the filter findLwby_Interfaces, the interface units obj28 and obj29 managed in the computer are displayed in the fields 46 in the object list 45. The properties of the first object obj28 are automatically displayed in the list of attributes 47.90: "Status
  • Detail window can either be selected by the user, for example by clicking on the field with the symbol "*", or opened automatically.
  • the entries in the attribute value 49 column can be displayed in a format-free manner, ie regardless of the data type of the attribute value.
  • the content of the properties, ie the attribute value can be converted into a uniform format suitable for generic representation, for example a character string.
  • the individual areas of the list window separated by dashed lines can optionally, step by step, only be displayed in the area above after the corresponding user input.
  • the display can, by means of a predetermined selection or default selection described later by way of example, be completely displayed without user input and filled in with data.
  • the object list 45 is preferably displayed to the user in a hierarchical tree structure which is not shown but is customary for browsers, for example. Such a tree structure of all objects can optionally be displayed in addition to the object list 45.
  • the user can have the properties or attributes displayed in different modes. He can choose to display the properties in one of the modes "View”, “Edit” or “Create”.
  • FIG. 5 shows method steps and exchanged messages in a client-server system, which enable properties of objects stored on the server side to be displayed in a client according to the invention.
  • Figure 5 shows in detail
  • a user (not shown) is offered a large number of base names that represent object classes.
  • the user can choose a base name.
  • request data for the properties of an object of the server software are sent 51, 55 from the client 20 to the server 10.
  • the requested properties are then determined in the server 10.
  • a naming convention is used, which is used in the server software for methods of objects in order to recognize the methods defined for the object.
  • the properties are then preferably determined using the recognized methods.
  • the properties are sent to the client 20 with a message 53, 56 and displayed in a step 33, 37, preferably for the user.
  • steps 31 to 33 and 35 to 37 follow the same principle.
  • steps 31 to 33 display methods as properties of an object on the client
  • steps 35 to 37 display attributes as properties of an object.
  • attributes are determined as requested properties, preferably as return values of the recognized methods
  • methods can be determined as requested Properties can be determined from the method names of the recognized methods.
  • the overall process shown in FIG. 5 can be regarded as a third embodiment.
  • the client 20 requests a list of the filters defined for the base name from the server 10.
  • a filter includes a name of the filter method and an optional number of filter parameters.
  • the server 10 recognizes the defined filters for an object class represented by the base name as an object by examining the methods of the object class.
  • a naming convention for filter methods is observed in the server software, which enables the filter methods to be recognized among the methods. For example, filter methods can be prefixed with "findLwBy". The server software therefore recognizes the filter methods by their names.
  • the server 10 can examine the object for its filter parameters, for example if these can be derived from the names of the filter methods as additional information.
  • the filters determined in this way are sent from server 10 to client 20.
  • the filters are offered for selection in a step 33 to the user (not shown), who uses an optional user input to select the filter F1 and a filter parameter FP1.
  • the client 20 requests from the server 10 a list of instances of the object class according to the filter method F1 with the filter parameter FP1.
  • the objects are filtered on the server 10.
  • a list of the objects of the object class, which is optionally filtered according to the selected filter, is sent to the client 20 with a message 54.
  • the user (not shown) can select an object, for example object 01, from the list of objects that is displayed to him.
  • a message 55 requests the attributes of the object 01 from the server 10.
  • the server software examines object 01 for its attributes.
  • the message 55 can be used, for example, to send a reference to the object 01 and either the request 51 or the basic name of the object class to the server 10 within the request data of the message 55.
  • the server software recognizes the properties of instances of the object class on the basis of the name of the object class and a naming convention for interface methods which provide the properties of the instances of the object class.
  • all attributes or properties of objects that are to be made available by the server 10 for the client 20 can be identified with a prefix "get_ ⁇ attribute name>".
  • the server software can thus examine the object or the object class of the instance for methods of the corresponding naming convention in order to determine which properties the object 01 has. The same method can then be used to determine the property.
  • the attributes determined in this way which thus vary according to data type, number of properties and of course their content, are transmitted to the client computer in order to a step 37 to be displayed to the user in a correspondingly flexible structure in the client 20.
  • Each of the selection steps 31, 33 and 35 shown in FIG. 5 can be replaced by a predefined default selection.
  • the preset default selection is to automatically choose a first base name from possible base names, to use an alphabetical sorting as a filter and to automatically select a first object in the object list.
  • the selection steps correspond to a selection in the elements 42, 43 and 45, which are shown in the list window 41 in FIG.
  • Such a default selection could either be used immediately at the beginning of the display of the list window 41 or after a certain period of time without user input.
  • the properties of an object can also be displayed, for example, in a separately but automatically opened detail window.
  • the request data preferably include a reference to the object. For example, either the name of the object or a pointer to the object can be transmitted to the server computer.
  • the attribute name as additional information can be contained in the method name ("get_ ⁇ attribute name>”), but can also be determined as a return value together with the method (“get_A10" returns the attribute name and value).
  • Additional information can be the number of properties of the object and the data type of the properties.
  • a method name prefix can be used to specify the data type. For example, a method that passes a character with "get_c_”, a method that passes a number, start with "get_n_” and a method that transfers a character string with "get_s_”.
  • a method that begins with a prefix “get_T_” can pass a reference to an object that still needs to be translated depending on the programming language, while a function "get_R_ ⁇ base name>” passes a reference to another object that can only be opened by opening a further detail window is displayed on the client server.
  • the step of determining the additional information thus takes place on the server 10, but it remains open to evaluate the additional information in the server 10 or only in the client 20.
  • the additional information can be sent to the client 20 with the requested properties.
  • the server 10 it can be decided on the server 10 which attributes should be visible to an object on the client 20.
  • the naming convention for its interface method is simply not adhered to. This method is not recognized and the attribute is therefore not displayed.
  • the selection of the properties to be displayed can be changed or new object types or classes can be introduced without having to adapt the corresponding client software to display the properties. This is a major step forward, particularly when using a large number of servers in different tiers and with the usual large number of clients served by one server.
  • either object-oriented interfaces CORBA, RMI, DCON
  • message-based interfaces are used in the server software and the client software.
  • client software consisting essentially of the graphical user interface, for example in the form of a browser, CGI-BIN, ULC or HTTP can also be used as interface specifications.
  • server computer can also function as a client or the client computer can also act as a server for other applications.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Human Computer Interaction (AREA)
  • Stored Programmes (AREA)
  • Digital Computer Display Output (AREA)
  • Computer And Data Communications (AREA)

Abstract

Die Erfindung betrifft zum Anzeigen von Eigenschaften eines Objektes einer Server-Software auf einer Anzeigeeinrichtung eines Client-Rechners, folgende Schritte: Senden (51, 55) von Anforderungsdaten für die Eigenschaften eines Objektes der Server-Software von dem Client-Rechner an den Server-Rechner, Ermitteln (32, 36) der angeforderten Eigenschaften in dem Server-Rechner, Senden (52, 56) der ermittelten Eigenschaften von dem Server-Rechner an den Client-Rechner, Anzeigen (33, 37) der gesendeten Eigenschaften auf der Anzeigeeinrichtung des Client-Rechners, wobei der Schritt des Ermittelns (32, 36) der Eigenschaften eine vorbestimmte Namenskonvention, die für Methoden von Objekten der Server-Software verwendet wird, anwendet, um die für das Objekt definierten Methoden am Methodennamen zu erkennen, und die Eigenschaften mittels der erkannten Methoden bestimmt.

Description

Beschreibung
Verfahren, Vorrichtung und Speichermedium mit Software zum Anzeigen von Eigenschaften eines Objektes einer Server- Software in einem Client-Rechner
Die Erfindung betrifft ein Verfahren, einen Client-Rechner, einen Server-Rechner sowie ein Speichermedium mit entsprechender Software zum Anzeigen von Eigenschaften eines Objektes einer Server-Software in einem Client-Rechner sowie vorzugsweise die Behandlung von tabellarischen Ob ekt-Listen- Fenstern in Netzwerkmanagement-Systemen.
Die zentrale Verwaltung von heterogenen Netzwerken wird mit einer steigenden Anzahl von zu verwaltenden Diensten und Schnittstellen immer komplexer. Einen wesentlichen Aspekt bildet hierbei die Verwaltung der physikalischen und logischen Verbindungen in einem heterogenen Netzwerk.
Selbst für einen einzelnen Rechner eines Netzwerk muss dabei eine Vielzahl von Verbindungen verwaltet werden. Beispielsweise kann der Rechner physikalisch mit dem Netzwerk und einer Vielzahl weiterer Untereinheiten, wie lokaler Drucker oder Festplatte, verbunden sein. Zusätzlich können parallel eine Vielzahl logischer Verbindungen des Rechners zu anderen Rechnern des Netzwerkes, in das Internet oder andere Netze bestehen.
In einer objektorientierten Software zur Verwaltung der Verbindungen dienen dabei Objekte als programmtechnische
Repräsentation für Vorrichtungen, beispielsweise eine Verbindungsleitung, einen IP-Router oder dessen Untereinheiten, und auch für abstrakte logische Daten, beispielsweise eine Verbindung, einen Bereich oder einen Kommunikationsendpunkt. Die Verbindungsdaten werden dann als Attribute der Objekte verwaltet. Beispielsweise für eine logische Verbindung zwischen zwei Rechnern könnte ein Objekt Verbindung! angelegt werden, das als Attribute Rechnerl , Rechner2 und Verbindungstypl enthält.
Die in der Software zur Verwaltung der Verbindungen vorhandenen Daten müssen dabei beispielsweise einem
Administrator des Netzwerkes zur Verfügung gestellt werden, damit dieser die Daten überwachen oder anpassen kann. Auch um die Daten für den Administrator nicht nur an einem einzigen Endgerät oder Arbeitsplatz verfügbar zu machen, werden die Daten von einem Server für eine Vielzahl von Endgeräten als Clients bereitgestellt.
Als minimale Funktion ist dabei in den Clients eine graphische Benutzerschnittstelle (GUI) bereitzustellen, die serverseitig gespeicherte Daten für einen Benutzer auf einer Anzeigeeinheit des Clients darstellen kann.
Ein Beispiel eines auf einem Bildschirm eines Clients dargestellten Fensters als graphische Benutzeroberfläche ist in Fig. 6 gezeigt. Das entsprechende Verfahren zwischen
Server und Client zum Anzeigen der Daten ist mit seinen wesentlichen Schritten und Nachrichtenflüssen in Fig. 7 dargestellt.
In Fig. 6 sind unter einer Titelzeile 61 des Fensters ein Auswahlfeld 62 für Filtermethoden und ein Eingabefeld für Filter-Parameter 63 dargestellt. Weiterhin umfasst das Fenster eine Liste für Attribute 64 bis 66, die in Feldern 67 bis 69 für Objekte eines Objekttypl dargestellt werden. Die Filter dienen dabei einer Einschränkung oder Sortierung der anzuzeigenden Datenmenge.
In diesem Fenster können jedoch nur Attribute von Objekten eines Objekttyps Objekttypl angezeigt werden. Da jeder Typ von Objekten unterschiedliche Filter-Methoden sowie Filter- Parameter und in Art oder Anzahl unterschiedliche Attribute 64 bis 66 enthält, wird für jeden Objekttyp ein speziell angepasstes Fenster verwendet.
Das Nachrichtenflussdiagramm in Fig. 7 zeigt einen Server 70 und einen Client 80. Zunächst wählt in einem Schritt 71 ein nicht dargestellter Benutzer einen Objekttyp aus und bekommt daraufhin das Fenster aus Figur 6 angezeigt.
Dem Benutzer werden in einem Schritt 72 die für den Objekttyp bekannten, fest in der graphischen Benutzerschnittstelle einprogrammierten Filtermethoden sowie zugehörigen Filterparameter zur Auswahl angezeigt. Nach Auswählen einer Filtermethode Fl und Eingabe von Filterparametern FPl sendet der Client 80 eine Anforderung 81 für eine gefilterte Objektliste an den Server 70. In diesem wird in einem Schritt 73 eine Filterung von Objekten gemäß der angeforderten Filtermethode Fl und der angeforderten Filter-Parameter FPl durchgeführt. Als Ergebnis wird eine Liste von Objekten erhalten, die für den Objekttyp in der Server-Software bekannt sind. Diese Liste wird mit einer Nachricht 82 an den Client 80 gesandt.
Optional wird in dem Client in einem Schritt 74 von dem Benutzer eines der ihm angezeigten Objekte ausgewählt und mit einer Nachricht 83 die Eigenschaften des ausgewählten Objektes angefordert.
Mit einer Nachricht 84 erhält der Client die Attribute AI bis A3 für ein oder mehrere Objekte. Diese zeigt er schließlich in einem Schritt 75, beispielsweise in den Feldern 67 bis 69 der Fig. 6, an.
Üblicherweise sind also die dem Benutzer angezeigten Eigenschaften, in Form der angebotenen Filter-Methoden, Filter-Parameter und anzuzeigenden Attribute, fest in dem Programmcode des Fensters aus Fig. 6 einprogrammiert. Häufig kommt serverseitig ein weiterer Objekttyp hinzu oder es ändert sich die Auswahl der Eigenschaften eines Objekttyps, die ein Server für den Client anbieten möchte. In diesen Fällen wird für die Client-Software ein neues Fenster programmiert oder die Programmierung der vorhandenen Fenster angepasst. Somit muss dann die gesamte Client-Software zur Darstellung der Fenster neu übersetzt und gelinkt werden.
Für das Verbindungsmanagement-System ist es also notwendig die Client-Software bzw. dessen GUI in allen Clients des
Systems anzupassen, wenn sich aus Änderungen oder Ergänzungen in dem System neue Eigenschaften für bekannte Objekte oder neue bisher nicht bekannte Objekttypen ergeben.
Aufgabe der vorliegenden Erfindung ist es, ein Verfahren, einen Client-Rechner, einen Server-Rechner sowie Speichermedien mit entsprechender Software zum Anzeigen von Eigenschaften serverseitig gespeicherter Objekte in einem Client-Rechner bereitzustellen, die eine Änderung der Art oder Anzahl von Eigenschaften eines Objektes in der Server- Software unabhängig von einer entsprechenden Änderung der Client-Software ermöglichen.
Diese Aufgabe wird durch die Gegenstände der unabhängigen Patentansprüche gelöst. Die abhängigen Patentansprüche beschreiben bevorzugte Ausführungsformen der Erfindung.
Ein Aspekt der vorliegenden Erfindung ist das Anzeigen von Eigenschaften für Objekte verschiedener Typen in einem einzigen flexiblen Fenster in einem Client-Rechner. Dafür werden in einem Server-Rechner die Objekte auf ihre für sie definierten Eigenschaften untersucht. Das Untersuchen auf definierte Eigenschaften wird dabei insbesondere ermöglicht durch Einhalten einer entsprechenden Namenskonvention für Klassen und deren Methoden in dem Server-Rechner. Als Objekt kann hier sowohl eine Instanz der Klassen als auch die Klasse selbst gesehen werden. Die Einhaltung einer entsprechend angepassten Vererbungshierarchie für die Klassen und Objekte der Server-Software kann ein solches Verfahren unterstützen.
Gemäß der Erfindung umfasst ein Verfahren zum Anzeigen von Eigenschaften von Objekten einer Server-Software auf einer Anzeigeeinrichtung eines Client-Rechners, wobei ein Objekt eine programmtechnische Struktur ist, welche die Eigenschaften und aufrufbare Methoden aufweist, folgende Schritten: Senden von Anforderungsdaten für die Eigenschaften eines Objektes der Server-Software von dem Client-Rechner an den Server-Rechner, Ermitteln der angeforderten Eigenschaften in dem Server-Rechner, Senden der ermittelten Eigenschaften von dem Server-Rechner an den Client-Rechner, Anzeigen der gesendeten Eigenschaften auf der Anzeigeeinrichtung des Client-Rechners, wobei der Schritt des Ermitteins der
Eigenschaften eine vorbestimmte Namenskonvention, die für Methoden von Objekten der Server-Software verwendet wird, anwendet, um die für das Objekt definierten Methoden am Methodennamen zu erkennen, und die Eigenschaften mittels der erkannten Methoden bestimmt.
Somit können Eigenschaften von Objekten, die auch eine für den Client unbekannte Struktur aufweisen können, in einer graphischen Benutzeroberfläche auf dem Client-Rechner angezeigt werden. Zudem kann für das Anzeigen von
Eigenschaften verschiedener Objekttypen in dem Client-Rechner das gleiche flexible Fenster einer GUI verwendet werden. Dieses flexible Fenster muss dann auch bei Einführung von neuen Objekttypen im Server-Rechner nicht mehr angepasst werden.
Gemäß einer bevorzugten Ausgestaltung des Verfahrens werden in dem Schritt des Ermitteins die angeforderten Eigenschaften als Rückgabewerte eines Aufrufs der erkannten Methoden bestimmt. Methoden, die Eigenschaften als Rückgabewerte ihres Aufrufs bereitstellen sind häufig bereits vorhanden. Dann müssen in der Server-Software lediglich diese Methoden nach der vorbestimmten Namenkonvention benannt werden, um die gewünschte Flexibilität zu erreichen. Weiterhin kann in der Server-Software eine zentrale Funktion den Schritt des Ermitteins für alle Objekttypen ausführen, wodurch weiterer Codierungsaufwand eingespart wird. Zusätzlich ist es auf diesem Wege möglich, für eine Methode, die als Rückgabewert eine Eigenschaft liefert, durch Verwenden oder Nichtverwenden der vorbestimmten Namenkonvention zu entscheiden, ob der Rückgabewert dieser Methode auf einem Client-Rechner als Eigenschaft angezeigt wird.
Gemäß einer weiteren Ausgestaltung des Verfahrens werden in dem Schritt des Ermitteins die angeforderten Eigenschaften aus den Methodennamen der erkannten Methoden bestimmt. Somit können als Eigenschaften des Objekts neben Attributen auch Informationen über die für das Objekt definierten Methoden angezeigt werden. Neben der Ermittlung von für das Objekt definierten Methoden kann durch eine entsprechend angepasste Namenskonvention in dem Methodennamen auch weitere Information enthalten sein.
Vorzugsweise werden in dem Schritt des Sendens von Anforderungsdaten Filter angefordert, die für das Objekt definiert sind, wobei in dem Schritt des Ermitteins die erkannten Methoden Filtermethoden sind. Somit können einem Benutzer an der Anzeigeeinrichtung des Client-Rechners unabhängig vom Objekttyp Filter zur Auswahl bereit gestellt werden, die beispielsweise eine Einschränkung oder Auswahl von Objekten vornehmen können, deren Eigenschaften in einem weiteren Schritt angezeigt werden sollen.
Besonders vorteilhaft ist es, aus dem Namen der Filtermethoden zumindest die Anzahl oder die Art der für die Filtermethode definierten Filterparameter zu bestimmen. Auf diesem Wege können allein durch Erkennen und Auswerten der
Filtermethodennamen die definierten Filter und eine für jeden Filter variable Anzahl oder Art von Parametern ermittelt werden.
Gemäß einer bevorzugten Ausgestaltung des Verfahrens werden in dem Schritt des Ermitteins weiterhin Zusatzinformationen zu den Eigenschaften des Objektes ermittelt. Somit kann der Schritt des Anzeigens der Eigenschaften des Objekts entsprechend der Zusatzinformation flexibel angepasst oder die Eigenschaften des Objekts in einer der Zusatzinformation entsprechenden Weise aufbereitet werden. Als
Zusatzinformation kann beispielsweise der Name einer anzuzeigenden Eigenschaft ermittelt werden, können Filterparameter bestimmt werden oder Eigenschaften, wie Referenzen auf andere Objekte oder sprachabhängig zu ersetzende Eigenschaften, entsprechend verwaltet werden.
Gemäß einer weiteren bevorzugten Ausgestaltung des Verfahrens sind die erkannten Methoden Schnittstellenmethoden für die Eigenschaften des Objekts, die als Zusatzinformation in ihrem Methodennamen die Namen der Eigenschaften umfassen. Somit kann aus dem Methodennamen der Name der Eigenschaft abgeleitet und als Zusatzinformation verwendet werden.
Vorzugsweise sind in der Server-Software zur Laufzeit der Server-Software Objekte gespeichert, die eine Objektklasse repräsentieren, wobei Instanzen der Objektklasse zur Laufzeit der Server-Software erzeugt und gespeichert werden können oder Objekte gespeichert werden, die eine Instanz einer Objektklasse sind. Möglich ist hier auch, eine erste Gruppe von Objekten zu verwenden, denen jeweils eine Vielzahl von Objekten zugeordnet sein kann. Für den Fall solcher zugeordneter oder abgeleiteter Objekte sind mehrstufige Verfahren denkbar, um zunächst die für ein Objekt definierten Objekte zu ermitteln, um dann die Eigenschaften der ermittelten Objekte anzuzeigen. Gemäß einer bevorzugten Ausführungsform eines solchen Verfahrens umfasst der Schritt des Sendens von Anforderungsdaten weiterhin die Schritte eines Sendens einer Listenanforderung, die eine Liste von Objekten gemäß eines ersten Filters anfordert, von dem Client-Rechner an den Server-Rechner und eines Sendens der anhand des ersten Filters in dem Server bestimmten Liste von Objekten von dem Server-Rechner an den Client-Rechner sowie eines Anzeigens der Liste von Objekten in dem Client-Rechner für ein mögliches Auswählen des Objektes aus der Liste von Objekten. Somit kann einem Benutzer eine Objektliste angeboten werden, aus der er ein einzelnes Objekt auswählen kann, dessen Eigenschaften er betrachten möchte.
Bei einer vorteilhaften Ausgestaltung des Verfahrens umfasst der Schritt des Sendens von Anforderungsdaten weiterhin die Schritte eines Sendens einer Filteranforderung von dem Client-Rechner an den Server-Rechner, ein Auswerten der Filteranforderung in dem Server-Rechner, wobei die für das Objekt definierten Filtermethoden anhand eines vorbestimmten Namensanteils in Namen von Filtermethoden bestimmt werden, eines Sendens der ermittelten Filter von dem Server-Rechner an den Client-Rechner sowie eines Anzeigens der empfangenen Filter in dem Client-Rechner für ein Auswählen eines zweiten Filters aus den empfangenen Filtern. Vorzugsweise ist der zweite Filter der vorbenannte erste Filter. Somit wird das erfindungsgemäße Verfahren in einer zweistufigen Form anwendbar.
Gemäß der Erfindung kann ein Client-Rechner und/oder ein
Server-Rechner angepasst sein bzw. Mittel enthalten, um in einem Client-Server-System die entsprechenden Schritte des beschriebenen Verfahrens auszuführen.
Ein Speichermedium kann gemäß der Erfindung eine ausführbare Kommandosequenz oder Client- bzw. Server-Software enthalten, die angepasst ist, auf einem Client- bzw. Server-Rechner die entsprechenden Schritte des beschriebenen Verfahrens auszuführen.
Im folgenden werden bevorzugte Ausführungsformen der Erfindung anhand der Zeichnungen beschrieben, welche im einzelnen zeigen:
Fig. 1 eine schematische Darstellung eines Client-Server- Systems gemäß der Erfindung;
Fig. 2 eine schematische Darstellung der Einheiten eines
Server- oder eines Client-Rechners;
Fig. 3 eine schematische Darstellung einer einfachen Vererbungshierarchie für Objektklassen;
Fig. 4 eine Darstellung einer graphischen Benutzeroberfläche gemäß der Erfindung;
Fig. 5 ein Nachrichtenflussdiagramm in einem Client-
Server-System gemäß der Erfindung;
Fig. 6 eine Darstellung einer Benutzeroberfläche gemäß dem Stand der Technik;
Fig. 7 ein Nachrichtenflussdiagramm für ein Verfahren in einem Client-Server-System gemäß dem Stand der Technik.
Zunächst werden für ein Netzwerkmanagement-System oder Verbindungsmanagement-System am Beispiel der Figuren 1 bis 3 die grundlegenden Begriffe vertieft, bevor die Erfindung insbesondere mit Bezug auf die Figuren 4 und 5 erläutert wird.
Fig. 1 zeigt ein Client-Server-System mit einem Server 10, der eine Server-Software 11 sowie eine optionale Datenbank 12 umfasst. In der Server-Software 11 ist ein Objekt 13 bis 15 dargestellt. Der Server-Rechner 10 ist mit einer Vielzahl von Client-Rechnern 20a bis 20c verbunden, die jeweils eine Client-Software 21a bis 21c aufweisen.
Die Client-Software 21a bis 21c zeigt für einen nicht dargestellten Benutzer auf einer Anzeigevorrichtung 22a bis 22c des Client-Rechners 20a bis 20c eine graphische Benutzeroberfläche an, die zur Visualisierung von Eigenschaften des serverseitig gespeicherten Objekts 13 bis 15 dient.
Das Objekt 13 bis 15 ist ein Objekt einer nicht dargestellten Vielzahl von Objekten in der Server-Software 11. Für eine bevorzugte Ausführungsform ist in Fig. 1 seine innere Struktur dargestellt. Neben der Kernfunktionalität 13 des Objekts umfasst es eine erste Schnittstelle 14, zur Bereitstellung der Eigenschaften des Objekts oder seiner Instanzen, und eine zweite Schnittstelle 15, die beispielsweise Funktionen zum Erzeugen von Instanzen des Objekts oder dessen Filtermethoden bereitstellt. Es ist anzumerken, dass die als Server-Software bezeichnete Einheit 11 lediglich eine Komponente der auf dem Server 10 ablaufenden Software sein kann.
Fig. 2 zeigt eine schematische Darstellung der wesentlichen Einheiten eines Rechners.
Ein Server-Rechner wird üblicherweise eine CPU 23, einen Speicher 24 zur persistenten Datenspeicherung beispielsweise der Serversoftware, einen Arbeitsspeicher 25 sowie eine externe Schnittstelle 28 zur Anbindung des Server-Rechners an das Client-Server-System beispielsweise über ein Netzwerk umfassen.
Eigenschaften von Objekten der Server-Software können temporär im Arbeitsspeicher 25 oder persistent im Speicher 24 gespeichert sein. Die Eigenschaften können aber auch in einer separaten Datenbank abgelegt sein, die über die externe Schnittstelle 28 oder über eine optionale interne Schnittstelle 29 mit dem Server-Rechner verbunden sein kann.
Optional umfasst der Server-Rechner eine Eingabeeinheit 26 sowie eine Ausgabeeinheit 27, die beispielsweise zur Administration der Server-Software einsetzbar sind.
Ein Client-Rechner wird zumindest eine CPU 23, einen
Arbeitsspeicher 25, eine Ausgabeeinheit 27, vorzugsweise eine Anzeigeeinrichtung, und die externe Schnittstelle 28 umfassen. Über die externe Schnittstelle 28 ist der Client- Rechner mit dem Client-Server-System beispielsweise über das Netzwerk verbunden.
Sinnvollerweise umfasst der Client-Server einen Speicher 24 zur persistenten Speicherung der Client-Software, die über eine externe Schnittstelle 28 von einem Server Daten erhält, welche die Eigenschaften von Objekten umfassen. Die
Eigenschaften können dann mittels der Ausgabeeinheit 27 für den Benutzer anzeigt werden.
Üblicherweise umfasst der Client-Rechner weiterhin eine Eingabeeinheit 26, um Benutzereingaben beispielsweise in Antwort auf angezeigte Daten zu ermöglichen.
Eingabeeinheiten 26 können dabei eine Vielzahl von Untereinheiten, wie beispielsweise Tastatur, Maus, Mikrophon oder berührungsempfindliche Bildschirme aufweisen. Auch
Ausgabeeinheiten 27 können eine Vielzahl von Untereinheiten, wie beispielsweise Bildschirm, Lautsprecher und Drucker umfassen.
Fig. 3 zeigt ein Beispiel einer Vererbungshierarchie für die in einer Server-Software verwendete Vielzahl von Klassen B0 bis B32. Üblicherweise werden die Klassen B0 bis B32 voneinander abgeleitet. Die Klasse B21 ist von der Klasse Bll abgeleitet, die wiederum von der Klasse BO abgeleitet wurde.
Eine Klasse ist dabei eine durch entsprechenden Programmcode definierte Struktur, die beispielsweise in den
Programmiersprachen JAVA oder C++ geschrieben sein kann. In einer Klasse können Methoden und Attribute definiert werden. Die Attribute weisen dabei einen Attributnamen sowie einen Attributwert auf, der als Datenfeld oder Inhalt des Attributs aufgefasst werden kann. Methoden sind Daten verarbeitende ausführbare Programmstrukturen, die auch als aufrufbare Methoden oder Funktionen bezeichnet werden können. Sie können einen optionalen Eingabewert verarbeiten und als Ergebnis einen optionalen Rückgabewert liefern. Eine Klasse wird eindeutig durch ihren Namen gekennzeichnet, der auch als Basisname bezeichnet wird.
Zur Laufzeit der Server-Software wird eine Klasse durch ein Objekt repräsentiert. Instanzen einer Klasse können als weitere Objekte erzeugt werden. Die Server-Software weist also eine Vielzahl von Objekten auf, die sowohl Klassen als auch Instanzen der Klassen sein können. Für die Objekte sind sowohl Attribute als auch Methoden definiert, die beide als Eigenschaften der Objekte bezeichnet werden.
Beispielsweise könnte der Rechner aus Figur 2 in der Serversoftware durch ein Objekt Rechnerl dargestellt werden, das eine Instanz der Klasse Hardware_Rechner ist, die wiederum aus der Klasse Hardware abgeleitet ist. Die Einheiten 23 bis 29 können als Objekte Obj23 bis Obj29 durch
Instanzen einer Klasse Hardware_Untereinhei t dargestellt werden. Eine Server-Software in dem Rechner kann nun auf Anforderung die Eigenschaften der Objekte Rechnerl oder Obj23 bis Obj29 an einen Client-Rechner senden, der die Eigenschaften anzeigen soll. Üblicherweise verwaltet eine
Server-Software auch Eigenschaf en weiterer Einheiten aus dem von ihr verwalteten Netzwerk. In diesem Beispiel wird aus Gründen der Transparenz auf deren Berücksichtigung verzichtet.
Durch die Strukturierung des Objektes 13 bis 15 in der Server-Software 11 in Figur 1 ist bereits eine mögliche Implementierung der Server-Objekte durch Enterprice Java Beans (EJB) angedeutet. Bei Verwendung von EJBs unterscheidet man üblicherweise zwischen Session Beans, die im wesentlichen temporäre Daten speichern, und Entity Beans, deren Eigenschaften persistent gespeichert werden.
Das Objekt 13 bis 15 stellt eine Entity Bean dar. Es besteht aus einem Home-Interface 15, welches Methoden zum Erzeugen oder Vernichten von Instanzen der Entity Bean ("create" oder "delete") sowie die entsprechenden Filtermethoden ("find") umfasst, einem Remote-Interface 14, in welcher die Schnittstellenmethoden ("get" und "set") zur Bereitstellung der Eigenschaften des Objekts enthalten sind, und die eigentliche Kernfunktion 13 oder Bean. Einer einfachen Namenskonvention folgend heißen die drei entsprechenden Klassen "<Basisname>Home" , "<Basisname>Remote" und "<Basisname>Bean" .
Die Namen der Filter-Methoden beginnen mit dem Präfix "findLwBy", während in dem Remote-Interface 14 die
Schnittstellenmethoden zum Ermitteln eines Attributs mit dem Präfix "get_" beginnen.
Das Home-Interface 15 kann weiterhin eine Methode zum Erkennen einzelner Objekte oder Instanzen der Entity Bean bereitstellen. Der Name bzw. die Existenz der Entity Bean kann dem Client dabei über eine zusätzliche nicht dargestellte Komponente, wie dem "Java Name Directory Interface" (JNDI), bekannt sein.
Figur 4 zeigt ein Fenster mit einer Liste von Objekten und deren Eigenschaf en, wie es von einer graphischen Benutzeroberfläche einer Client-Software in einem Client- Rechner auf dessen Bildschirm oder Ausgabeeinheit angezeigt wird.
Neben einer Titelleiste 41 des Listenfensters ist ein Auswahlfeld 42 für einen Basisnamen, der einen Namen einer Objektklasse repräsentiert, ein Auswahlfeld 43 für eine Filtermethode sowie ein Eingabefeld 44 für optionale Filterparameter dargestellt.
Weiterhin ist neben einer Liste von Objekten 45, in welcher beispielsweise Objektnamen in den Feldern 46 angezeigt werden, eine Liste von Attributen oder Eigenschaften mit zwei Spalten Attributname 47 und Attributwert 49 mit entsprechenden Feldern 48 und 50 angezeigt.
Die Liste der Objekte 45 und die Liste der Attribute 47, 49 sind dabei in ihrer Zeilenzahl variabel ausgestaltet.
Für das beschriebene Beispiel des Rechners aus Figur 2 wird als Basisname Hardware__Untereinhei t von dem Benutzer eingegeben oder aus einer Liste von Basisnamen ausgewählt. Dann werden die für das Objekt dieser Klasse definierten Filtermethoden ( findLwby_Name, findLwby__Interfaces, ...) im Feld 43 zur Auswahl angeboten. Nach Auswahl des Filters findLwby_Interfaces werden in der Objektliste 45 die in dem Rechner verwalteten Schnittstelleneinheiten obj28 und obj29 in den Feldern 46 angezeigt. Automatisch werden für das erste Objekt obj28 in der Liste der Attribute 47,90 dessen Eigenschaften angezeigt: "Status | extern, maximale Datenrate | 56kB, aktive Verbindungen | *". Das Symbol "*" deutet einerseits an, dass aktive Verbindungen über die externe Schnittstelle bestehen. Andererseits zeigt es weiterhin an, dass diese Eigenschaften nicht in der Spalte 49, sondern nur in einem Detailfenster dargestellt werden können. Das
Detailfenster kann entweder nach einer Auswahl des Benutzers, beispielsweise durch Anklicken des Feldes mit dem Symbol "*", oder automatisch geöffnet werden.
Weiterhin können die Einträge in der Spalte Attributwert 49 formatfrei, also unabhängig vom Datentyp des Attributwerts, dargestellt werden. Dazu kann beispielsweise der Inhalt der Eigenschaften, also der Attributwert, in ein einheitliches zur generischen Darstellung geeignetes Format, beispielsweise eine Zeichenfolge, konvertiert werden.
Die einzelnen durch gestrichelte Linien getrennten Bereiche des Listenfensters können optional, schrittweise erst nach der entsprechenden Benutzereingabe in dem darüber liegenden Bereich angezeigt werden. Das Anzeigen kann, durch eine später beispielhaft beschriebene vorbestimmte Auswahl oder Defaultauswahl, ohne eine Benutzereingabe vollständig angezeigt und mit Daten ausgefüllt werden.
Ferner wird vorzugsweise die Objektliste 45 dem Benutzer in einer nicht dargestellten, aber beispielsweise für Browser üblichen, hierarchischen Baumstruktur angezeigt. Eine solche Baumstruktur aller Objekte kann optional zusätzlich zur Objektliste 45 angezeigt werden.
Nicht dargestellt ist in Fig. 4 ebenfalls, dass der Benutzer die Eigenschaften oder Attribute in verschiedenen Modi anzeigt bekommen kann. So kann er wahlweise die Eigenschaften in einem der Modi "Betrachten", "Bearbeiten" oder "Erzeugen" anzeigen lassen.
Das Nachrichtenflussdiagramm der Fig. 5 zeigt Verfahrensschritte und ausgetauschte Nachrichten in einem Client-Server-System, die ein erfindungsgemäßes Anzeigen serverseitig gespeicherter Eigenschaften von Objekten in einem Client ermöglichen. Im einzelnen zeigt Figur 5 ein
Nachrichtenflussdiagramm zwischen Server 10 und Client 20 in einem Netzwerkmanagement-System. Neben Schritten 31 bis 37 sind Nachrichten 51 bis 56 dargestellt, die zwischen dem Server 10 und dem Client 20 ausgetauscht werden.
Unter Bezugnahme auf Fig. 5 werden im Folgenden exemplarisch drei bevorzugte Ausführungsformen der Erfindung beschrieben, welche die Schritte 31 bis 33 und/oder 35 bis 37 umfassen.
Dabei wird einem nicht dargestellten Benutzer in einem optionalen Schritt 31 eine Vielzahl von Basisnamen, die Objektklassen repräsentieren, zur Auswahl angeboten. Der Benutzer kann einen Basisnamen auswählen.
Zunächst werden Anforderungsdaten für die Eigenschaften eines Objektes der Serversoftware von dem Client 20 zum Server 10 gesendet 51, 55. In Schritten 32, 36 werden die angeforderten Eigenschaften dann im Server 10 ermittelt. Dabei wird eine Namenskonvention ausgenutzt, die in der Server-Software für Methoden von Objekten verwendet wird, um die für das Objekt definierten Methoden zu erkennen. Vorzugsweise mittels der erkannten Methoden werden dann die Eigenschaften bestimmt.
Mit einer Nachricht 53,56 werden die Eigenschaften an den Client 20 gesandt und in diesem in einem Schritt 33,37, vorzugsweise für den Benutzer, angezeigt.
Es wird deutlich, dass die Schritte 31 bis 33 sowie 35 bis 37 nach dem gleichen Prinzip ablaufen. Der Unterschied zwischen diesen beiden Ausführungsformen ist zunächst darin zu sehen, dass mit den Schritten 31 bis 33 Methoden als Eigenschaften eines Objekts auf dem Client angezeigt werden, während mit den Schritten 35 bis 37 Attribute als Eigenschaften eines Objekts angezeigt werden.
Während die Attribute als angeforderte Eigenschaften vorzugsweise als Rückgabewerte der erkannten Methoden bestimmt werden, können Methoden als angeforderte Eigenschaften aus den Methodennamen der erkannten Methoden bestimmt werden.
Als dritte Ausführungsform kann der in Fig. 5 dargestellte Gesamtablauf angesehen werden.
Mit der Anforderungsnachricht 51 fordert der Client 20 von dem Server 10 eine Liste der für den Basisnamen definierten Filter an. Dabei umfasst ein Filter einen Namen der Filtermethode sowie eine optionale beliebige Anzahl von Filterparametern .
Der Server 10 erkennt die definierten Filter für eine durch den Basisnamen repräsentierte Objektklasse als Objekt, indem er die Methoden der Objektklasse untersucht. In der Server- Software wird eine Namenskonvention für Filtermethoden eingehalten, die es ermöglicht die Filtermethoden unter den Methoden zu erkennen. Beispielsweise können Filtermethoden einheitlich mit einem Präfix "findLwBy" versehen sein. Die Server-Software erkennt also die Filtermethoden an ihren Namen .
Weiterhin kann der Server 10 das Objekt auf seine Filterparameter untersuchen, beispielsweise wenn diese als Zusatzinformation aus den Namen der Filtermethoden abgeleitet werden können.
In der Nachricht 52 werden die so bestimmten Filter von dem Server 10 an den Client 20 gesendet. In dem Client 20 werden die Filter in einem Schritt 33 dem nicht dargestellten Benutzer zur Auswahl angeboten, der durch eine optionale Benutzereingabe den Filter Fl und einen Filterparameter FPl auswählt .
Mit einer Nachricht 53 fordert der Client 20 von dem Server 10 eine Liste von Instanzen der Objektklasse gemäß der Filtermethode Fl mit dem Filterparameter FPl an. In einem Schritt 34 erfolgt diese Filterung der Objekte auf dem Server 10.
Eine Liste der Objekte der Objektklasse, die optional gemäß dem ausgewählten Filter gefiltert ist, wird mit einer Nachricht 54 an den Client 20 gesandt. In einem Schritt 35 kann der nicht dargestellte Benutzer aus der erhaltenen Liste der Objekte, die ihm angezeigt wird, ein Objekt, beispielsweise das Objekt 01, auswählen.
Eine Nachricht 55 fordert von dem Server 10 die Attribute des Objekts 01 an. In einem Schritt 36 untersucht die Server- Software das Objekt 01 auf seine Attribute. Dazu kann mit der Nachricht 55 beispielsweise eine Referenz auf das Objekt 01 sowie entweder mit der Anforderung 51 oder innerhalb der Anforderungsdaten der Nachricht 55 der Basisname der Objektklasse an den Server 10 gesandt werden.
In dem Server 10 erkennt die Server-Software die Eigenschaften von Instanzen der Objektklasse anhand des Namens der Objektklasse und einer Namenskonvention für Schnittstellenmethoden, welche die Eigenschaften der Instanzen der Objektklasse bereitstellen.
So können beispielsweise alle Attribute oder Eigenschaften von Objekten, die von dem Server 10 für den Client 20 verfügbar gemacht werden sollen, mit einem Präfix "get_<Attributname>" gekennzeichnet sein. Somit kann die Server-Software beim Auswerten das Objekt bzw. die Objektklasse der Instanz auf Methoden der entsprechenden Namenskonvention untersuchen, um zu bestimmen, welche Eigenschaften das Objekt 01 besitzt. Die gleiche Methode kann dann zur Bestimmung der Eigenschaft verwendet werden.
In einer Nachricht 56 werden die so bestimmten Attribute, die also nach Datentyp, Anzahl der Eigenschaften und natürlich ihrem Inhalt variieren, zum Client-Rechner übertragen, um in einem Schritt 37 in einer entsprechend flexiblen Struktur in dem Client 20 für den Benutzer angezeigt zu werden.
Jeder der in Figur 5 dargestellten Auswahlschritte 31, 33 und 35 kann durch eine vorab definierte Default-Auswahl ersetzt werden. Beispielsweise bietet sich als voreingestellte Default-Auswahl an, automatisch einen ersten Basisnamen von möglichen Basisnamen zu wählen, als Filter eine alphabetische Sortierung zu verwenden und ein erstes Objekt der Objektliste automatisch zu selektieren. Die Auswahlschritte entsprechen einer Auswahl in den Elementen 42, 43 und 45, die im Listenfenster 41 der Figur 4 dargestellt sind. Eine solche Default-Auswahl könnte entweder sofort zu Beginn der Darstellung des Listenfensters 41 oder nach Ablauf einer gewissen Zeitspanne ohne Benutzereingabe verwendet werden.
Das Anzeigen der Eigenschaften eines Objekts kann dabei beispielsweise auch in einem separat aber automatisch geöffneten Detail-Fenster erfolgen. Die Anforderungsdaten umfassen vorzugsweise eine Referenz auf das Objekt. Es kann beispielsweise entweder der Name des Objektes oder ein Zeiger auf das Objekt an den Server-Rechner übertragen werden.
Durch die vorbestimmte Namenskonvention können in den Methodennamen noch weitere Zusatzinformationen zu den
Eigenschaften des entsprechenden Objekts kodiert werden. Der Attributname als eine Zusatzinformation kann im Methodennamen enthalten sein ( "get_<Attributname>" ) , aber auch als Rückgabewert zusammen mit der Methode bestimmt werden ("get_A10" liefert Attributname und -wert).
Als Zusatzinformation kann sich einerseits die Anzahl der Eigenschaften des Objekts ergeben und andererseits auch der Datentyp der Eigenschaften. Beispielsweise kann ein Präfix für Methodennamen verwendet werden, der den Datentyp spezifiziert. So könnte eine Methode, die ein Zeichen übergibt, mit "get_c_", eine Methode, die eine Zahl übergibt, mit "get_n_" und eine Methode, die eine Zeichenkette übergibt, mit "get_s_" beginnen.
Weiterhin können somit auch komplexere Datentypen voneinander unterschieden und entsprechend behandelt werden.
Beispielsweise kann eine Methode, die mit einem Präfix "get_T_" beginnt, eine Referenz auf ein abhängig von der Programmiersprache noch zu übersetzendes Objekt übergeben, während eine Funktion "get_R_<Basisname>" eine Referenz auf ein anderes Objekt übergibt, das erst durch Öffnen eines weiteren Detailfensters auf dem Client-Server angezeigt wird.
Der Schritt des Ermitteins der Zusatzinformation erfolgt also auf dem Server 10, es bleibt jedoch offen, die Zusatzinformation im Server 10 oder erst im Client 20 auszuwerten. Die Zusatzinformation kann mit den angeforderten Eigenschaften an den Client 20 gesandt werden.
In dem erfindungsgemäßen System kann auf dem Server 10 entschieden werden, welche Attribute auf dem Client 20 für ein Objekt sichtbar sein sollen. Für ein Attribut, welches nicht angezeigt werden soll, wird einfach die Namenskonvention für seine Schnittstellenmethode nicht eingehalten. Diese Methode wird nicht erkannt und das Attribut somit nicht angezeigt.
Die Auswahl der anzuzeigenden Eigenschaften kann geändert werden oder es können neue Objekttypen oder -klassen eingeführt werden, ohne dass die entsprechende Client- Software zur Darstellung der Eigenschaften angepasst werden muss. Dies ist insbesondere bei der Verwendung einer Vielzahl von Servern in verschiedenen Schichten sowie bei der üblichen Vielzahl von Clients, die von einem Server bedient werden, ein wesentlicher Fortschritt.
Für den Benutzer ist es möglich, allein durch Angabe des Basisnamens in einem Fenster automatisch und generisch in diesem Fenster die Attribute oder Eigenschaften beliebiger Objekte angezeigt zu bekommen.
Um ein dynamisches Casten mittels des "Liskov Substitution Principle" zu gewährleisten, muss für die Klassen der Server- Software eine bestimmte Vererbungshierarchie eingehalten werde .
In einer bevorzugten Ausgestaltungsform werden in der Server- Software und der Client-Software entweder objektorientierte Schnittstellen (CORBA, RMI, DCON) oder nachrichtenbasierte Schnittstellen verwendet. Im Falle einer im wesentlichen aus der graphischen Benutzerschnittstelle, beispielsweise in Form eines Browsers, bestehenden Client-Software können ferner als Schnittstellen-Spezifikationen beispielsweise CGI-BIN, ULC oder HTTP verwendet werden.
Neben dem einfachen in Fig. 1 gezeigten System mit zwei Schichten, in welchem auch eine Vielzahl von Servern mit der Vielzahl von Clients verbunden sein könnte, sind beispielsweise auch mehrschichtige Modelle insbesondere durch Auslagern der optionalen Datenbank 12 in eine eigene Rechnereinheit denkbar. Grundsätzlich kann für andere Anwendungen der Server-Rechner auch als Client oder der Client-Rechner auch als Server fungieren.
Es ist offensichtlich, dass die Anwendung der beschriebenen Verfahren auf beliebige Systeme mit zumindest zwei Schichten erfolgen kann.

Claims

Patentansprüche
1. Verfahren zum Anzeigen von Eigenschaften von Objekten einer Server-Software auf einer Anzeigeeinrichtung eines Client-Rechners, wobei ein Objekt eine programmtechnische Struktur ist, welche die Eigenschaften und aufrufbare Methoden aufweist, mit folgenden Schritten:
Senden (51,55) von Anforderungsdaten für die Eigenschaften eines Objektes der Server-Software von dem Client-Rechner an den Server-Rechner;
Ermitteln (32,36) der angeforderten Eigenschaften in dem Server-Rechner;
Senden (52,56) der ermittelten Eigenschaften von dem Server- Rechner an den Client-Rechner; und
Anzeigen (33,37) der gesendeten Eigenschaften auf der Anzeigeeinrichtung des Client-Rechners;
wobei der Schritt des Ermitteins (32,36) der Eigenschaften eine vorbestimmte Namenskonvention, die für Methoden von Objekten der Server-Software verwendet wird, anwendet, um die für das Objekt definierten Methoden am Methodennamen zu erkennen, und die Eigenschaften mittels der erkannten Methoden bestimmt.
2. Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass in dem Schritt des Ermitteins (36) die angeforderten
Eigenschaften als Rückgabewerte eines Aufrufs der erkannten Methoden bestimmt werden.
3. Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass in dem Schritt des Ermitteins (32) die angeforderten
Eigenschaften aus den Methodennamen der erkannten Methoden bestimmt werden.
4. Verfahren nach Anspruch 3 dadurch gekennzeichnet, dass in dem Schritt des Sendens (51) von Anforderungsdaten Filter angefordert werden, die für das Objekt definiert sind, und in dem Schritt des Ermitteins (31) die erkannten Methoden Filtermethoden sind.
5. Verfahren nach Anspruch 4 dadurch gekennzeichnet, dass aus den Namen der Filtermethoden zumindest die Anzahl oder die Art der für die Filtermethode definierten Filterparameter bestimmt wird.
6. Verfahren nach einem der Ansprüche 1 bis 5 dadurch gekennzeichnet, dass der Schritt des Ermitteins (32,36) in dem Server-Rechner weiterhin ein Ermitteln von
Zusatzinformation zu den Eigenschaften des Objekts umfasst.
7. Verfahren nach Anspruch 6 dadurch gekennzeichnet, dass in der Server-Software eine Vielzahl von Objekten verwendet wird, die sich in Anzahl und Art ihrer Eigenschaften unterscheiden können, und der Schritt des Anzeigens (33,37) durch das Verwenden der Zusatzinformation an die Vielzahl der Objekte anpassbar wird.
8. Verfahren nach Anspruch 6 oder 7 dadurch gekennzeichnet, dass ein Schritt eines Auswertens der Zusatzinformation in dem Server-Rechner oder nach einem Senden der Zusatzinformation an den Client-Rechner in dem Client-Rechner erfolgt.
9. Verfahren nach einem der Ansprüche 6 bis 8 dadurch gekennzeichnet, dass als Zusatzinformation die Namen der im Client-Rechner anzuzeigenden Eigenschaften bestimmt werden und die Namen der Eigenschaften in dem Schritt des Anzeigens (33,37) der Eigenschaften auf der Anzeigeeinrichtung des Client-Rechners mit den Eigenschaften angezeigt werden.
10. Verfahren nach einem der Ansprüche 6 bis 9 dadurch gekennzeichnet, dass die erkannten Methoden Schnittstellenmethoden für die Eigenschaften des Objekts sind, die als Zusatzinformation in ihrem Methodennamen die Namen der Eigenschaften umfassen.
11. Verfahren nach einem der Ansprüche 1 bis 10 dadurch gekennzeichnet, dass die Anforderungsdaten eine Referenz auf das Objekt umfassen.
12. Verfahren nach einem der Ansprüche 1 bis 11 dadurch gekennzeichnet, dass das Objekt eine Objektklasse repräsentiert, wobei Instanzen der Objektklasse zur Laufzeit der Server-Software erzeugt und gespeichert werden können.
13. Verfahren nach einem der Ansprüche 1 bis 11 dadurch gekennzeichnet, dass das Objekt eine Instanz einer Objektklasse ist, die zur Laufzeit der Server-Software in dem Server-Rechner gespeichert ist .
14. Verfahren nach einem der Ansprüche 1 bis 13 dadurch gekennzeichnet, dass der Schritt des Sendens (55) von Anforderungsdaten weiterhin die folgenden Schritte umfasst:
Senden (53) einer Listenanforderung, die eine Liste von Objekten gemäß eines ersten Filters anfordert, von dem Client-Rechner an den Server-Rechner;
Senden (54) der anhand des ersten Filters in dem Server bestimmten Liste von Objekten von dem Server-Rechner an den Client-Rechner;
Anzeigen (35) der Liste von Objekten in dem Client-Rechner für ein Auswählen des Objektes aus der Liste von Objekten.
15. Verfahren nach einem der Ansprüche 1 bis 14 dadurch gekennzeichnet, dass der Schritt des Sendens (55) von Anforderungsdaten weiterhin die folgenden Schritte umfasst:
Senden (51) einer Filteranforderung von dem Client-Rechner an den Server-Rechner;
Auswerten (32) der Filteranforderung in dem Server-Rechner, wobei die für das Objekt definierten Filtermethoden anhand eines vorbestimmten Namensanteils in Namen von Filtermethoden bestimmt werden;
Senden (52) der ermittelten Filter von dem Server-Rechner an den Client-Rechner;
Anzeigen (33) der empfangenen Filter in dem Client-Rechner für ein Auswählen eines zweiten Filters aus den empfangenen Filtern.
16. Verfahren nach einem der Ansprüche 1 bis 15 dadurch gekennzeichnet, dass auf dem Server-Rechner Daten eines Netzwerkmanagement-Systems verwaltet werden, die einem Administrator des Netzwerkmanagement-Systems in der Anzeigeeinrichtung des Client-Rechners als die Eigenschaften des Objekts angezeigt werden.
17. Client-Rechner, der angepasst ist, in einem Client- Server-System, ein Verfahren nach einem der Ansprüche 1 bis 16 auszuführen.
18. Server-Rechner, der angepasst ist, in einem Client- Server-System ein Verfahren nach einem der Ansprüche 1 bis 16 auszuführen.
19. Speichermedium enthaltend eine ausführbare
Kommandosequenz oder Client-Software, die angepasst ist, auf einem Client-Rechner in einem Client-Server-System ein Verfahren nach einem der Ansprüche 1 bis 16 auszuführen.
20. Speichermedium enthaltend eine ausführbare Kommandosequenz oder Server-Software, die angepasst ist, auf einem Server-Rechner in einem Client-Server-System ein Verfahren nach einem der Ansprüche 1 bis 16 auszuführen.
PCT/DE2002/003648 2001-09-28 2002-09-26 Verfahren, vorrichtung und speichermedium mit software zum anzeigen von eigenschaften eines objektes einer server-software in einem client-rechner WO2003030481A2 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002339329A AU2002339329A1 (en) 2001-09-28 2002-09-26 Method, device and storage medium comprising software for displaying properties of an object of server software in a client computer

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10147872A DE10147872A1 (de) 2001-09-28 2001-09-28 Verfahren, Vorrichtung und Speichermedium mit Software zum Anzeigen von Eigenschaften eines Objektes einer Server-Software in einem Client-Rechner
DE10147872.0 2001-09-28

Publications (2)

Publication Number Publication Date
WO2003030481A2 true WO2003030481A2 (de) 2003-04-10
WO2003030481A3 WO2003030481A3 (de) 2003-09-18

Family

ID=7700625

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2002/003648 WO2003030481A2 (de) 2001-09-28 2002-09-26 Verfahren, vorrichtung und speichermedium mit software zum anzeigen von eigenschaften eines objektes einer server-software in einem client-rechner

Country Status (3)

Country Link
AU (1) AU2002339329A1 (de)
DE (1) DE10147872A1 (de)
WO (1) WO2003030481A2 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102007039531A1 (de) * 2007-08-21 2009-02-26 Endress + Hauser Process Solutions Ag Verfahren zum Beschaffen von instandhaltungsrelevanten Informationen zu einer Anlage

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2332335A (en) * 1997-12-10 1999-06-16 Northern Telecom Ltd Network management system
US6175866B1 (en) * 1997-11-24 2001-01-16 International Business Machines Corporation Method and system for generating unsupported network monitoring objects
US6282568B1 (en) * 1998-12-04 2001-08-28 Sun Microsystems, Inc. Platform independent distributed management system for manipulating managed objects in a network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6175866B1 (en) * 1997-11-24 2001-01-16 International Business Machines Corporation Method and system for generating unsupported network monitoring objects
GB2332335A (en) * 1997-12-10 1999-06-16 Northern Telecom Ltd Network management system
US6282568B1 (en) * 1998-12-04 2001-08-28 Sun Microsystems, Inc. Platform independent distributed management system for manipulating managed objects in a network

Also Published As

Publication number Publication date
AU2002339329A1 (en) 2003-04-14
DE10147872A1 (de) 2003-04-30
WO2003030481A3 (de) 2003-09-18

Similar Documents

Publication Publication Date Title
DE69729926T2 (de) Netzwerkbrowser
DE10051021B4 (de) System, Verfahren und Computerprogramm zur Bereitstellung interaktiver Web-Inhalte in statisch verknüpften Dateien
DE69817158T2 (de) Benutzerschnittstellen-Mechanismus zur Manipulierung von Kontexten in Computerverwaltungsapplikationen
DE69630480T2 (de) Verfahren, Vorrichtung und Datenstrukturen zur Objektverwaltung
DE69636914T2 (de) Verfahren und Vorrichtung für Netzwerkverwaltung
DE19522185A1 (de) Ein Verfahren und System zur dynamischen Übersetzung zwischen verschiedenen grafischen Benutzeroberflächen-Systemen
DE102005013305A1 (de) Verfahren und System zum Verwalten elektronischer Systeme
EP1587244B1 (de) Verfahren zur Konfiguration einer Filtervorrichtung für einen in Frames organisierten Datenstrom, und Protokolltester
DE102006010535A1 (de) Verfahren zum Bereitstellen von aktualisierten Protokollen in einem medizinischen Radiologie-Informationssystem
DE10218812A1 (de) Generische Datenstrombeschreibung
WO2003027896A2 (de) Visualisierung eines vergleichsergebnisses mindestens zweier in verzeichnisbäumen organisierter datenstrukturen
DE60032403T2 (de) Speziell adaptierte Wiedergabe und Darstellung von Datenbankinformationen
EP2171582B1 (de) Fernbedienung eines browser-programms
DE69831502T2 (de) Verfahren zum erzeugen von filtern, welche das einbruchrisiko in verbundene rechnernetze verhindern
WO2005038662A2 (de) Betriebsverfahren für einen server und hiermit korrespondierende gegenstände
WO2003030481A2 (de) Verfahren, vorrichtung und speichermedium mit software zum anzeigen von eigenschaften eines objektes einer server-software in einem client-rechner
DE69929474T2 (de) Eine softwareentwicklungsstruktur
EP1515244A2 (de) Abbildung einer Klassenhierarchie auf ein relationales Datenbanksystem
DE10310886B3 (de) Verfahren und System zum gleichzeitigen Anzeigen desselben Inhalts auf zu verschiedenen Computern gehörenden Bildschirmen, sowie Web-Seite mit einem Link zu einem Dienst
WO2002037339A2 (de) System, verfahren und computerprogramm zur konfiguration von objekten
DE19957883A1 (de) Verfahren zur Erzeugung grafischer Programmoberflächen
EP1388786A1 (de) Benutzerschnittstelle für eine Mensch-Computer Interaktion
EP0877986B1 (de) Verfahren zum aufteilen eines elektronischen dokuments für ein netzwerkinformationssystem mit hilfe eines rechners
DE19612688A1 (de) Verfahren und Vorrichtung zur dynamischen Anpassung von Computer-gesteuerten Geschäftsprozessen
DE10203775A1 (de) Verfahren und Systemkonfiguration zum Verarbeiten von Daten eines Online-Systems

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BY BZ CA CH CN CO CR CU CZ DK DZ EC EE ES FI GB GD GE GH GM HR ID IL IN IS JP KE KG KP KR KZ LC LK LS LT LU LV MA MD MG MK MN MW MZ NO NZ OM PH PL PT RO RU SD SE SI SK SL TJ TM TN TR TT TZ UA UG UZ VC VN YU ZA ZM

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ UG ZM ZW AM AZ BY KG KZ RU TJ TM AT BE BG CH CY CZ DK EE ES FI FR GB GR IE IT LU MC PT SE SK TR BF BJ CF CG CI GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP