WO2002101550A1

WO2002101550A1 - Adding a new service in a distributed object component network

Info

Publication number: WO2002101550A1
Application number: PCT/FI2002/000495
Authority: WO
Inventors: Jari VÄNTTINEN; Pekka Luukas; Joose NIEMISTÖ; Jukka Tomminen; Jonne Itkonen; Jouni Korte; Santtu Toivonen; Antti Luoranen
Original assignee: Sonera Oyj
Priority date: 2001-06-08
Filing date: 2002-06-07
Publication date: 2002-12-19
Also published as: FI20015009A; FI20015009A0

Abstract

A method for service collaboration between a new service (81) and an existing service (82) in a distributed object component network (DOCN) in which services are implemented as sets of one or more service components (3c - 3m; 71 - 76). The new service (81) registering itself (8-0) with a service repository (SR) and advertises its existence (8-2) via a communication channel (NC) that reports (8-4) the existence of the new service (81) to the existing service (82). The existing service (82) requests (8-8) and obtains (8-10) details of the new service (81) from the service repository (SR). It then connects (8?14) to the new service (81). A benefit of the invention is that the existing service (82) can make use of the new service (81) without restarting the existing service (82).

Description

ADDING A NEW SERVICE IN A DISTRIBUTED OBJECT COMPONENT NETWORK

Background of the invention

The invention relates to methods and equipment for a distributed object component network. More particularly the invention relates to methods for providing services and a service repository within such a network.

Traditionally, software systems have been built by algorithmic decomposition, in which a software developer decomposes the system into modules such that each module represents a major step in the overall process. This approach has led to the top-down programming paradigm. A general problem with this paradigm is that, as the system evolves, its original design tends to break up. Changes in the implementation of the algorithms and data structures often require changes to the program that use them. This means that the coupling between different system parts is too tight, and results in a phenomenon known as architectural erosion which finally makes the system so complicated that the developers of two separate system parts do not seem to speak the same language. The general problem can be expressed in more technical terms by saying that modules are poorly or not at all reusable within a platform and poorly or not at all interoperable between different platforms.

In object-oriented computing (OOC), the developer's focus moves from algorithms and data flows to objects with data and inter-object collaboration. The focus is on the key abstractions in the problem domain. The abstractions are identified and classified into different classes. Encapsulating the data associated with the classes reduces coupling between different classes and methods. The external representation of the system remains the same al- though the internal representation may change.

CORBA (Common Object Request Broker Architecture) is a set of specifications by OMG (Object Management Group). CORBA specifications define an open, low-level architecture that offers flexible design options and basic distribution technology. However, CORBA does not offer a complete en- vironment for developing distributed applications. The limitations of CORBA are best apparent in object reusability within an application or a platform, object interoperability between applications or platforms and load balancing (scalability).

A partial solution is disclosed in US patent 6085030 to R. White- head et al. However, in the Whitehead patent the focus is on locating components in a distributed network. Object interoperability, or how the objects are combined to perform useful services and applications, remains largely an open question. A specific problem underlying the invention is the difficulty in making existing services cooperate with new (emerging) services.

Disclosure of the invention Thus the invention generally aims at addressing the limitations of the known component object paradigms, such as CORBA. The methods and equipment according to the invention should be able to perform useful services and applications by combining distributed network objects such that object interoperability and reusability is good and service/application develop- ment is flexible. A more particular objective of the invention is to develop methods and equipment for service cooperation between new and existing services.

This objective is achieved with methods and equipment which are characterized by what is disclosed in the attached independent claims. Pre- ferred embodiments of the invention are disclosed in the attached dependent claims.

An aspect of the invention is a distributed object computing network (DOCN) which exhibits the desirable characteristics above. Yet another aspect of the invention are the various methods which are carried out by the DOCN network.

In the following description, the term 'client' should be understood in the context of client-server architectures. A client can be anything that accesses services, such as human users and internal and external software entities. The term 'user' is restricted to human users. According to a preferred embodiment of the invention there is provided a method for service collaboration between a new service and an existing service in a distributed object component network in which services are implemented as sets of one or more service components. The method comprises the following steps. The new service registers itself with a service re- pository and advertises its existence to the existing service via a communication channel. The existing service then requests and obtains details of the new service from the service repository. It then connects to the new service. A benefit of this method is that the existing service can make use of the new service without restarting the existing service. The communication channel is preferably a notification channel substantially in accordance with CORBA specifications. According to another preferred embodiment of the invention, the authentication further comprises assigning one of several predetermined roles to the client on the basis of the authenticating step and associating each role with a set of access rights to the service components or sets thereof, the service components or sets implementing the service. A benefit of this feature is that the client does not have to be authenticated in respect of individual service components or component sets. To improve security, the authenticating step may further comprise mapping the client's identifier in an external data network to a unique identifier in the distributed object component network. The unique identifier is preferably concealed from entities outside the distributed object component network.

The role-assigning step preferably comprises providing the client with an object reference to a component holding the role. The object reference is preferably an object reference substantially in accordance with CORBA specifications. The object reference preferably expires automatically after a predetermined lifetime. Clients with similar access rights can be combined into a group, and each client is assigned an identifier of the group.

A preferred method for implementing the services comprises receiving a service request from the client. On the basis of the service request, the client is provided with the requested service. The service-provisioning step further comprises accessing a service factory that determines the set of service components required to implement the service and prepares the set by locating existing sen/ice components or by instantiating new ones. External clients are preferably authenticated before service provisioning. To improve service cooperation, the service repository preferably comprises an ontology database containing an ontological description of services and the step of requesting/obtaining details of the new service comprises sending an inquiry into the ontology database. An ontological description of services facilitates provisioning of services having complex and human- oriented relations. The client is preferably provided with a software agent for cooperating with the ontology database in order to provide the client with additional services related to the service indicated by the service request from the client.

Brief description of the drawings The invention will be described in more detail by means of preferred embodiments with reference to the appended drawing wherein: Figure 1 illustrates a logical layer model of a distributed component network according to the invention;

Figure 2 shows a software component and its interfaces;

Figure 3A is a block diagram illustrating an external client using an application of a distributed object component network (DOCN) according to an embodiment of the invention;

Figure 3B illustrates the concept of a DOCN identity;

Figure 4 is a signalling diagram illustrating an internal client using an application of a DOCN according to an embodiment of the invention; Figure 5 is a signalling diagram illustrating an external client using a

DOCN application;

Figure 6 is a signalling diagram which extends Figure 5 by the concept of roles;

Figures 7A and 7B illustrate the concept of roles in service access; Figure 8 illustrates new service registration;

Figures 9A and 9B illustrate two implementations of an ontology database;

Figures 10A through 10C, which form a single logical image, illustrate an example of an ontology database for a movie theatre and its related services;

Figure 11 illustrates an extendible user interface which enables application providers to offer supporting services; and

Figure 12 illustrates copying or moving service components.

Detailed description of the invention DOCN platform model

Figure 1 illustrates a logical layer model of a distributed component network (DOCN) according to the invention. Reference number 11 denotes a node, which is the most fundamental layer of the network architecture. It represents a computational entity of a network. A node offers the network some fundamental services, such as the creation and deletion of an environment for executing component containers (component homes). A hardware implementation of a node is a physical computer along with its operating system, network drivers, etc. The operating system and drivers act as software adapters which make nodes compatible with each other. A component home 12 provides a runtime environment for components. A service network may comprise several different kinds of component homes. A component home is implemented by suitable software processes within a node. The processes of the component home offer the network some fundamental services, such as the creation and deletion of object components. A component 13 is the smallest part of a reusable software object in the network. Core services, application services and applications are built from components.

Core services, one of which is denoted by reference numeral 14, are basic services of the network. They ensure that the network is operational, and that it is fault-tolerant, efficient, reliable and secure. Core services may also include low-level services to be used within any application or application service. Examples of the low-level sen/ices include naming service for finding components, timing service for synchronizing events, logging service for usage information, load balancing for an appropriate distribution of processing load, and access management for authentication, authorization and security.

Application services, one of which is denoted by reference numeral 15, are the topmost interfaces for application developers. They are high-level services which facilitate application development. If, say, certain functionality is needed in several applications, the functionality can be packed and distributed as application services for efficient reuse. Application services define ways of carrying out certain operations, such as communication services (gateways), interfaces to/from users (short messages, voice mail, e-mail, calendar, etc.), billing and end-user authentication. In addition, external legacy platforms (ie platforms not built according to the invention) and systems are typically in the application service layer.

An application 16 is a logical map of connections between the services that implement the application. It is a logical unit created dynamically at runtime. Each application has all the external information and business logic needed for operation. Applications are based on components residing in the service network, and they may use other components, core services, application services and applications.

A DOCN platform 17 is formed at runtime when parts of the different layers cooperate. The platform 17 includes all the layers 11 through 16 de- scribed above, plus the necessary software generation tools. A careful reader will observe that the term 'DOCN network' was also used above. The terms 'network' and 'platform' can be used interchangeably. It is a clear benefit of the invention that the network is the platform. In other words, it does not matter where in the network a component is located. As long as a component resides in the network and is documented in the service repository according to the in- vention, it can be located and used for building higher-level structures.

After this short introduction of the layers, the layers will next be described in more detail.

Within the context of this invention, the term 'node' 11 means more than a networked computer. The purpose of a node, as used herein, is to iso- late the DOCN service network from the physical environment, ie the underlying physical data network and computers. Thus the node interface serves as an abstraction layer which makes all hardware and software types virtually interchangeable (as long as the capacity is sufficient). The node manages the component home processes so that they can be executed on virtually any kind of hardware or operating system. As seen from the DOCN, the node interface abstracts the underlying computer and operating system like a Java virtual machine separates Java byte code from its physical environment.

Another important purpose of the node is that it manages all the necessary core services. It is responsible for starting up and shutting down services, and for monitoring the functioning of particular services. Thus the node operates as a watchdog. It can also manage external systems, gateways, etc. A node also verifies that component homes are created with appropriate security settings.

A component home 12 acts as a logical container to the compo- nents. It is actually implemented as a process that runs (executes) components. The component home offers life-cycle services to the components. In other words, it creates, maintains and deletes components. The component home may also take care of security issues such as data encryption and decryption between different component homes and processes. Figure 2 shows a DOCN software component and its interfaces.

The components can be implemented by Enterprise Java Beans (EJB) technology. DOCN components 13 may have several functions at the same time. They can be used dynamically (at runtime) to construct different levels of services. For example, at any given time, a component can act as a client for a core service and a server for an application service, or vice versa. In the example shown in Figure 2, a component has three interfaces: a usage interface 21 , a control interface 22 and management interface 23. The component offers its functionality to its clients via the usage interface 21. The control interface 22 is for the management-related functionality that the component offers to its clients that do not need a complete management interface. An example of such functionality is the life-cycle management of a component. The management interface 23 is for the functionality that a component offers for system configuration and administration purposes.

A component's size and functionality are completely implementation-dependent. In other words, a designer or developer determines the level of functionality that justifies the creation of a component. A minimum-size component for beeping may have only one method for making beep sound. A larger component may include all the functionality for packaging the SMS (short message service) gateway. An even larger component may comprise a full database management system. Before implementing certain functionality as a component, a developer should determine what is the smallest software part that is feasible to wrap up for reuse or distribution.

All services needed to ensure the operability of the DOCN network are included in the core services 14. Table 1 presents an illustrative but non- exhaustive list of core services in a typical DOCN network.

Table 1 : typical core services The distinction between application services 15 and applications 16 is somewhat blurred. One can say that an application sen/ice is something which is worthwhile to generalize as a service. Again, a developer should determine what is the smallest logical software unit that is feasible to wrap up for reuse or distribution. For example, a banking application may use several functions, such as depositing, withdrawal and balance inquiry. If these functions can be used elsewhere, it may be feasible to implement them as application services.

Figure 1 should not be interpreted in the sense that there is a one- to-one relationship between any two of the layers 11 through 17. Rather the inter-layer boundaries act as abstraction layers hiding the details of lower ("inner") levels from higher levels. For example, one application 16 typically comprises several application services 15, and one application service may support several different applications. Similarly, there may be several different in- stances of a component home 12, eg for different security levels, and a node 11 may comprise several component homes.

Figure 3A is a block diagram illustrating a distributed component network DOCN according to a preferred embodiment of the invention. A client accesses the DOCN network with a client terminal CT. In this example, the cli- ent terminal is a mobile station which uses a telecommunication network, such as a GSM network, as an access network AN. The access network AN may be connected to the DOCN via a data network DN, such as an IP network. The DOCN is intentionally drawn on top of the data network DN, which means that they are not geographically distinct. Rather the DOCN can be seen as an up- per hierarchical level on top of the data network. In the DOCN, the client's first contact point is the client's peer entity PE.

In addition, the DOCN comprises one or more service factories SF which assemble useful services and applications from components 3c through 3m. Service factories are known from prior art technologies, such as CORBA. A service factory SF can assemble components into useful services and applications but it needs to be told which components should be assembled. For this purpose, the DOCN network comprises a service repository SR. In this example, the DOCN network employs three techniques for finding components. They are, in order of increasing intelligence, a naming service NS, a trading service TS and an ontology database OD. The naming service and the trading service are basically known from prior art technologies, such as CORBA. The naming service NS is analogous to the white pages of a telephone book: it converts a name into a network address. The trading service TS is also known from CORBA, and it corresponds to the telephone book's yellow pages. In other words, it locates objects on the basis of a descriptor. The service repository SR contains service descriptions which describe the run-time operation of the DOCN services. XML (extendible markup language) is a suitable language for creating the service descriptions. A service description includes the lifetime of the service and its semantic meaning. The semantic meaning may include a reference to other service descriptions, whereby the service repository contains tree-like inter-linked structures. The semantic descriptions are stored in the ontology database OD, which is a novel element of a DOCN network according to this embodiment of the invention. The ontology database extends the trading service TS (the yellow-pages concept) by locating objects, not only on the basis of a descriptor, but on the basis of relations between descriptors. For example, the ontology database OD may be able to determine that a person reserving a movie ticket to a theatre may also need parking facilities neat that theatre. The ontology database will be described later in more detail.

In the example shown in Figure 3A, the ontology database OD and the trading service TS are comprised in the service repository SR, but the trading service can also be external to the service repository SR.

The service repository SR, like any other service, can be implemented in a distributed manner. This means that the physical data structures describing the services can be located in different nodes (computers). Thus the service repository must create an illusion of a logically unitary ontology tree and ensure that the parts of the distributed ontology tree communicate with each other in order to return all the necessary information to an inquiring client.

A client may use DOCN services as follows. Arrow 30 denotes the client's initial contact to the DOCN. The initial contact indicates an application that the client wants to use. The peer entity PE receives the initial contact and processes it on the basis of client preferences, network situations, etc. In step

31 , the peer entity PE performs an inquiry to the service repository SR. In step

32, the service repository SR returns a list of services which can be used to build the client-requested application. In step 33, the peer entity PE directs the list of services to the service factory SF. In step 34, the service factory SF as- sembles the required application. In the simplistic illustration, the application is denoted by a group 3A of object components 3c through 3f. Figure 3A also shows another group 3B of components 3e through 3j. Group 3B implements another application to another client. Components 3e and 3f are common to groups 3A and 3B. In step 35, the service factory SF is notified that that the group 3A implementing the requested application is ready for execution. (Actually, no explicit notification 35 is needed. Rather the service factory SF knows that the components are ready because it receives no error messages.) In step 36, the service factory SF indicates the ready status of the application to the peer entity PE, which forwards the indication to the client in step 37. In step 38, the client begins to use the application implemented by group 3A .

The above steps 30 through 38 are basically known from prior techniques, such as CORBA, but a novel element of the invention lies in the tech- niques that the DOCN in general and the service repository SR in particular use to find and link together suitable services and service components.

Figure 3B illustrates the concept of a DOCN identity. Identities form logical trees which can be divided into network and service specific levels. At the network level, there is a DOCN-specific identity at the root of the identity tree. The branches of the tree contain ID groups that can be joined by means of the DOCN ID. Thus all services are introduced at the network level. At the service level, there are specific ID groups. The service-specific ID group is optional and the depth of the tree is up to the service developer.

For example, let us assume that a user wants to access a banking application. The service logic of the application does not concern the DOCN; the network only has to enable the user to find the banking service. The bank may have different services for normal credit customers and investors. Therefore the bank application developers can separate the logic of the different services and create roles (see Figures 6 and 7B) to support them.

In addition to external clients, one of which is denoted by the client terminal CT, the DOCN may comprise internal clients, and Figure 4 is a signalling diagram illustrating an internal client (such as a software agent) using a DOCN application. In Figure 4, the term 'location service' refers in general to any method of locating component references, such as the naming service NS or trading service TS in Figure 3A. In step 4-0, the client requests the location service to find a service. In step 4-1 , the location service gives the client a ref- erence to a service factory SF. In step 4-2, the client requests the service factory SF to create the service from suitable components. In step 4-4, the service factory SF creates the service, either by finding existing components or by instantiating new ones. In step 4-6, the service factory SF knows that all ser- vice components are ready for execution and reports this fact to the client. In step 4-8, the client begins to use the service. According to the invention, the location service gives the client a reference to a service factory SF, not to the actual service or its components. This feature of the invention facilitates object life-cycle management and load balancing, improves security, and increases service network performance.

Figure 5 is a signalling diagram illustrating an external client, such as the client terminal CT in Figure 3A, using a DOCN application. In steps 5-0 through 5-4, the client logs in to the DOCN via an access provider AP, which may be located in the access network AN or the data network DN. A preferred feature of the invention is that the client is assigned a DOCN identity (identifier) which is never conveyed outside of the DOCN. In steps 5-6 and 5-8, the client's service request is relayed to the peer entity, and from this point on, the remaining steps of Figure 5 are similar to the corresponding steps in Figure 4 if the peer entity acts as the internal client in Figure 4. Preferably, the access provider AP is adapted to achieve terminal- independence. In other words, the access provider AP acts as an interworking unit and protocol converter. As seen from the DOCN, all terminal types, such as GSM, PDA, WAP, PC, have a type-specific peer entity, and all terminal/peer entity combinations are equivalent. No situations will occur in which a terminal is unable to receive a service because services will never be offered to incompatible terminals. This can be ensured by user/client/terminal profiles which are assigned to a role in the DOCN. The concept of roles will be described later in more detail.

Another function of the access provider AP is user-independence and anonymity. Assuming that an access provider, such as the access network operator, wants to offer the DOCN services to its clients without revealing the identities of the clients to the DOCN operator. Concealment of the client identity from the DOCN may be required by law or driven by economic realities. In this case, the DOCN may use the access provider as a trusted client, and the access provider monitors service usage for billing purposes. A third benefit of a separate access provider AP is improved user/client authentication. All clients, whether internal or external, or agents or application using lower-level services, always operate on the basis of the DOCN identifier which is never revealed outside of the DOCN. Thus nobody can navigate in the DOCN by a different identity than what was used for authentication.

The peer entity does not necessarily involve much overhead. If the client is eg DOCN/CORBA-compliant, the peer entity is either not needed at all, or it is only a concept-level description that maps the client's external iden- tity to the DOCN identity.

DOCN security model

The DOCN security model can be based on the following concepts: DOCN identity, role/capability, secure communication channel and security logs. Each DOCN component has a unique DOCN identity (identifier). Accord- ing to a preferred feature of the invention, the DOCN identity is never conveyed outside of the DOCN. However, the system shown in Figure 3A can be implemented such that the client terminal CT is DOCN-compliant, in which case the DOCN extends as far as the CT (eg its SIM card or the like), but the DOCN identifier is nevertheless hidden from external clients or human users. Each DOCN identity can belong to one or more ID groups. The ID groups can be further grouped in a hierarchical manner. Each ID has one role (an active group binding) at a time. A role specifies the association between a client's DOCN ID and the ID group of the services used by the client. A service can further divide its ID groups to subgroups, which allows finer control of opera- tions available for the service users.

DOCN identities are assigned to human users, applications and nodes. Users are authenticated at login. Their identity is conveyed to the peer entity PE in the DOCN. Applications are identified when they connect to the DOCN. Internal applications are registered to the nodes and the component homes in which they are executed. Nodes are identifies when they are established to the DOCN.

Access restrictions can be implemented by means of capabilities. The capabilities in turn can be implemented as proxy objects delegating operation requests to the component implementation. A service factory instantiating the proxy object checks the client component's identity from the DOCN capability core service. Service access based on roles and capabilities

Figure 6 is a signalling diagram which extends Figure 5 by the concept of roles. The scenario shown in Figure 6 begins with steps 5-0 through 5-12 of Figure 5, but from that point on, Figures 5 and 6 differ. In Figure 5, the focus is in service location (finding service components), and data security aspects are ignored, apart from a generic login procedure. Figure 6 shows two elements, namely a capability service and a role proxy. Instead of keeping track of each client's rights to every possible service component, a preferred DOCN embodiment employs roles, such as "expert", "user", "boss" or "guest", and the rights are granted not to individual clients but to roles. After a successful login, each client is assigned one of several roles. The capability service employs a logical tree which comprises the client's ID, services and roles. This embodiment differs from prior art access right mechanisms in that the access right determination is front-heavy, which means that clients can only see ser- vices which they are entitled to see in their current roles. When clients access service components, there is no need to check if they are entitled to use the components because the clients cannot see components they are not entitled to use. In other words, if a client has a reference to a service component, it is assumed that the client is authorized to use that service component. This fea- ture is implemented by the role proxy as follows.

In step 6-14 (which follows step 5-12), the internal client (or peer entity PE) sends a request for service operation to the sen/ice factory SF. In step 6-16, the service factory SF checks, on the basis of the client's identity, if the client is entitled to use the requested service in the specified role. This check is carried out by sending an inquiry to the capability service CS. In step 6-18, the capability service CS reports that the client ID is consistent with the requested role. In step 6-20, the service factory SF requests the role proxy RP to create an instance of the requested role, which the role proxy confirms in step 6-22. In step 6-24, the service factory SF creates the requested service by selecting a suitable set of service components. In step 6-26, the client is notified that the requested service is ready for execution, and in step 6-28, the client sends the role proxy RP a request for operation which the role proxy delegates to the service components in step 6-30.

In prior art access control mechanisms, authentication is carried out in connection with every service call. Such techniques typically rely on access control lists (ACL). The role-based access control mechanism according to this embodiment of the invention is more efficient because only the step of role creation requires authentication, and the client is prevented from even seeing services which are beyond the privileges of its/his/her current role. This feature is described further in Figure 7B. It should be noted that a client can have mul- tiple roles (but only one at any given time), depending on the situation.

The role proxies RP help to solve a problem known as a confinement problem. Granting a capability (access) to a client is equivalent to the client receiving an object reference to the proxy. Object references can be passed between clients and servers, and between different servers. A client can not only pass a reference around, but also obtain the attribute values for a particular interface and call the methods defined in the interface. It is up to the client how this information is used and distributed. Some protection against the confinement problem is achieved by creating proxy components that are valid only for a predetermined period of time. The proxies should be time-stamped at creation, and they should destroy themselves when the predetermined validity period expires.

Figures 7A and 7B further illustrate the concept of roles in service access. Figure 7A illustrates a prior art technique in which each client C1 through C4 has specific access rights to each component 71 through 77. The collection of access rights is typically maintained by access control lists ACL. But with the proliferation of clients and services, maintenance of the access control lists becomes tedious. In a system as shown in Figure 7A, each component is visible to each client. The dash-dot line 78 represents an instant of such component-to-client visibility in which component 77 is visible (but not usable) to client C1. Each time a client C1 through C4 accesses a component 71 through 77, the client's access rights must be checked, which consumes time and resources.

Figure 7B illustrates a technique according to a preferred feature of the invention. In this case the clients C1 through C4 do not access compo- nents 71 through 77 directly but via a role proxy RP. The role proxy RP takes advantage of the fact that there are typically several clients with identical rights, such as clients C2 and C3 in Figure 7A. Clients with identical rights can share a common role, such as role R2 in Figure 7B. The concept of roles greatly simplifies access right maintenance. Clients do not need specific ac- cess rights to individual components but to roles. Unlike Figure 7A, Figure 7B does not comprise any dash-dot lines, which means that inaccessible compo- nents are not visible to the clients, whereby, in principle, an individual client's access rights to a component need not be checked. Rather the client's rights to use a certain role are checked, but only once. However, in important cases, such as banking services and the like, both check types (roles and access control lists to individual services) can be combined. In other words, although the client has been assigned a role, the client can nevertheless be authenticated again as soon as she/he/it begins to use a banking service. The word 'it' implies that a client can be a real person with a terminal or a software agent.

New service registration Figure 8 illustrates new service registration according to a preferred embodiment of the invention. According to this embodiment, new services register with the DOCN dynamically, without a need to restart existing services or network elements. A simple example of new service registration is a case in which a newer version of a given service is an improvement over an older ver- sion of a similar service. For example, GSM short messages were originally limited to 160 characters each, but more recent mobile stations support concatenation of multiple short messages, whereby higher protocol layers get an illusion of longer short messages. In the scenario shown in Figure 8, service A (denoted by reference number 81) represents such a new messaging service, and service B (denoted by reference number 82) is an existing service or application which makes use of the messaging service. In step 8-0, the new service A registers with the service repository SR. The registration comprises all the service details, characteristics, etc. In step 8-2, the new service 81 advertises its existence via a notification channel NC. In step 8-4, the notification channel reports the existence of the new service 81 to existing services, such as the existing service 82. The report comprises the type of the new service, such as a messaging service. In step 8-6 the existing service 82 checks the service type of the new service 81 , and determines that service 82 can use service 81. In step 8-8, the existing service 82 requests service details from the service repository SR, which returns the details in step 8-10. In step 8-12 the existing service 82 checks the details of the new service 81 , and in step 8- 14 connects to use the new service 81.

The notification channel NC is specified in CORBA specifications. Alternative communication channels are the system channel and event chan- nel of CORBA. The notification channel NC is the preferred communication channel, however, because it does not load entities which are not interested in new services.

In the above example, the existing service 82 determines compatibility with the new service 81 on the basis of version numbers (service 81 is a newer version of a messaging service). This is a rather simplistic example, and more interesting examples will be given in connection with an ontology database. Yet it is an important point that existing services or network elements do not have to be restarted, provided that they are designed to make use of new or improved services dynamically, ie "on the fly".

Ontology database

Webster's dictionary defines ontology as "a science or study of being; a branch of metaphysics relating to the nature and relations of being". A more practical description (in technical terms) can be found in references 1 and 2. The main purpose of an ontology or ontology database is to enable communication between computer systems in a way that is independent of the individual system technologies, information architectures and application domains. The key ingredients that make up an ontology are a vocabulary of basic terms and a precise specification of what those terms mean. An ontology is more than an agreed vocabulary. It provides a set of well-founded constructs that can be leveraged to build meaningful higher level knowledge. The terms in an ontology should be selected with great care, ensuring that the most basic (abstract) fundamental concepts and distinctions are defined and specified. The terms chosen form a complete set, whose relationship one to another is defined using formal techniques. It is these formally defined relationships that provide the semantic basis for the terminology chosen. An ontology is also more than a taxonomy or classification of terms. Although taxonomy contributes to the semantics of a term in a vocabulary, ontologies include richer relationships between terms. It is these rich relationships that enable the expression of domain-specific knowledge, without the need to include domain- specific terms.

Within the context of this invention, the term 'ontology' should be interpreted in light of the above description of an ontology, to distinguish the invention from prior art documents in which the term is used in a loose meaning. For example, US-patent 5920848 to Daniel Schutzer et al. discloses the use of intelligent agents for financial transactions, services, accounting, and advice. But, Schutzer uses the term 'ontology' for a very simplistic process in which a user can add new expense categories to his/her account, or delete existing ones. Schutzer's ontology is not a true ontology because one user's expense categories are not made available to others, nor is any attempt made to ensure that all users interpret the expense categories in the same way or use the same terms for similar categories.

Figures 9A and 9B illustrate two implementations of an ontology database OD. In both cases, the ontology database is implemented as a tree structure such that each service is a leaf of a tree. In Figure 9A, there is one tree 90. The purpose of the tree is to indicate similarities between different concepts. Reference numbers 91 to 93 denote three different concepts. (Actually each node is a concept, but only three have been provided with reference numbers.) Similarity between different concepts is determined on the basis of their characteristics. Some characteristics are essential (necessary) while some are incidental (potential/possible). In the example shown in Figure 9A, there is more similarity between concepts 92 and 93 than between any of the remaining pairs, ie 91 - 92 and 91 - 93. For example, concept 91 may be a calendar service, while 92 is a short message service and 93 is an e-mail service.

A primary benefit of the ontology database is that it extends the known trading services in object computing networks. In prior art trading service mechanisms, such as CORBA's, clients can retrieve services without knowing the specific names of the services. Thus the trading service is an analogy of a telephone book's yellow pages. But a client must still know what to look for. A software agent for finding movie theatres finds movie theatres but not supporting services, such as parking facilities or restaurants. Service access via the ontology database OD enables compliant software agents to find supporting services as well. For instance, the ontology database OD may indicate that, in addition to a movie ticket, a moviegoer may need parking facilities and nutrition. Figures 10A through 10C, which form a single logical image, illustrate such an ontology database OD for a movie theatre and its related services. This example involves four different ontologies, namely services 101 , entertainment 102, protocols 103 and terminals 104. Each of the topmost boxes 101 through 104 is the root node of its respective ontology tree. Figure 10A mainly illustrates the services ontology whose root is the services class 101. Figure 10A shows three classes of services, namely parking 105, movie theatres 106 and a calendar service 107. There is an 'extends' relationship from these sen/ices to the root 101 of the service ontology. This means that the services 105 through 107 are subclasses of the service class 101. Similarly, there is a parking facility 111 that is a subclass of parking class 105 and two movie theatres 112 and 113 that are subclasses of movie theatres class 106. There is a 'uses' relationship from the services 111 through 113 to the calendar service 107. In other words, the services 111 through 113 use the calendar service 107 to keep track of reservations, appointments, etc. There is an 'offers' relationship from the movie theatres class 106 to a movies class 121. The movies class 121 is depicted with dashed lines which means that it is actually located in an entertainment ontology shown in Figure 10B, so as not to unduly complicate Figure 10A. Likewise, there may be an 'offers' relationship from the parking class 105 to parking space (not shown).

Thus on a description level, one can say that the various services are subclasses of the ontology-based service repository, and on an implementation level, the service interfaces and service classes are instances of these services. In other words, a service network instance is an instance of a sen/ice which is an instance of the ontology-based service repository.

Although most relationships in Figure 10A follow the tree-like struc- tures shown in Figures 9A and 9B, there may be exceptions. For instance, there is a mutual 'advertises' relationship (or two one-way relationships) between Carl's parking 111 and Jim's Movies 112. This means that these two facilities have agreed to advertise each other's services. This kind of relationship can be deleted without otherwise affecting the services ontology shown in Fig- ure 10A.

Finally, Figure 10A shows a number of 'access' relationships. For instance, Joe's movies 113 has access to three protocols, namely HTTP 131 , SMS 132 and WAP 133, from a protocols ontology whose root node is box 103. The protocols ontology will be shown in more detail in Figure 10C. Figure 10B shows a section of the entertainment ontology. This example has three kinds of entertainment, namely movies 121 , literature 122 and music 123. For example, the music class 123 could be further subdivided into live and recorded music, and live music could be further subdivided according to genre, etc. Figure 10C shows representative sections of the remaining ontologies, namely protocols and terminals. The protocols ontology comprises HTTP 131 , SMS 132 and WAP 133. Node 104 is the root of the terminals ontology. Terminals are divided into wired terminals 141 and wireless terminals 142. In this example, the wired terminals class 141 has only one instance, namely personal computers (PCs) 143. There is a 'supports' relationship from the PC class 143 to the HTTP protocol 131 , which means that PCs are supposed to support the HTTP protocol. Wireless terminals 142 are divided into PDAs personal digital assistants (PDA) 144 and mobile phones 145. The latter class has two extensions, namely communicators 146 and WAP phones 147. All instances of the mobile phones class 145 (including extensions of the class, like communicators 146 and WAP phones 147) support the SMS protocol 132. Communicators 146 and WAP phones 147 also support the WAP protocol 133, and communicators also support the HTTP protocol 131.

The terminals ontology under node 104 can be further enhanced by associating the terminals with other properties besides supported protocols. For instance, communication speed can be expressed by introducing a connection type (not shown) having the terminal's maximum data rate as an attribute. The connection type can be joined by a relationship to terminals, such as mobile phones.

Figure 11 illustrates an extendible user interface which enables ap- plication providers to offer supporting services. Figure 11 shows two screens, 110 and 116, of the user interface Ul. In this example, the user interface relates to reserving movie tickets to a cinema called "Nostalgia". Section 111 of the first screen 110 comprises all the fields and other user interface elements which are needed to reserve movie tickets. Section 111 is illustrated in a sim- plified manner because its implementation is routine to person with ordinary skill in the art. The novelty of screen 110 is in section 112 which enables the cinema's application provider to provide or advertise related services to which no allowance was made when the user interface Ul or the underlying ticket reservation application was designed. In this example, section 112 comprises a drop-down box 113. A click to the down arrow of box 113 opens a scrollable list 114 of supporting services. Let us assume that a user selects "restaurants" and clicks the "details..." button 115. In response to selection of the button 115, the user is shown a second screen 116 of the user interface. In this example, the second screen 116 comprises previous/next buttons 117 and a "re- serve" button 118, the clicking of which enables the user to make a table reservation. A special feature of the invention, if implemented as shown in Figures 8 through 11 , is that users and other clients have access to new services without any special software. The user interface Ul shown in Figure 11 can be implemented by a standard web browser. Also, the designer of the movie ticket reservation system needs no prior knowledge of future supporting services. Rather the supporting services to be listed in box 114 are selected on the basis of the ontology database OD which is smart enough to know that a typical moviegoer may be interested in refreshments and parking or transport facilities but is not likely to have a haircut or appendix removal in connection with a movie. The user interface Ul shown in Figure 11 is not merely extendi- ble but hierarchically extendible. Let us illustrate this point by an example. Figure 11 shows the user interface Ul at a time when no car washes advertise their services in the DOCN. Let us further assume that the ontology database OD indicates that a moviegoer may wish to have his/her car washed during a movie. As soon as the first cooperating car wash begins to advertise, the user interface software creates a new screen 119 for the general category of car washes and a detail screen for the particular car wash. But all the information for creating the screen 119 is obtained from sources external to the ticket reservation application or its user interface software. The ontology database OD indicates that a car wash is a meaningful service for a moviegoer, and the details (addresses, etc.) is obtained from the car wash itself.

Yet further, it is not even necessary to restart the ticket reservation system to inform it about new supporting services. If new services are coupled by the process shown in Figure 8, the next moviegoer sees the new service as soon as s/he begins to use the ticket reservation system.

The above example provides an example to the higher-level structures shown in Figure 1. The reservation system for the movie theatre and the restaurant are applications 16. To keep track of the resources, the applications may employ a calendar service, which is an example of an application service 15. The application services in turn use core services 14, such as messaging, and other functions listed in table 1. The core services and application services are built from components 13 which are executed by components homes 12 in compatible nodes.

In summary, the ontology-based service repository offers a founda- tion for building extensible services and service groupings. The ontology database stores concepts with meanings and relations, on top of which it is possi- ble to build more complex relations. For example, a calendar-service- instanceX is an instance of calendar-service which is an instance of a service.

Load balancing

Figure 12 illustrates copying or moving service components. This feature is important for efficient load balancing because applications (more particularly: the components implementing the applications) can be copied or moved to nodes best suited to carry out the tasks involved. The elements participating in the copy or move are a DOCN administrator, the management interfaces of the original and copy objects, a component home and a service factory. In step 12-2, a client (a DOCN administrator) issues a copy command to the component to be copied (ie the original component), specifying the parameters that define where the new copy should be located and the parameters to define the attribute values of the component when the copy is created. In steps 12-4 and 12-6, the original component obtains a list of the factories that are able to create the desired component via a FindFactories() method of the component home interface. This method requires a key data type that identifies what component type is to be created. In step 12-8, the component calls the create() method of the factory and provides the key data type and the creation parameters of the call. In steps 12-10 and 12-12, the client obtains a reference to the newly-created copy of the component, which is activated in step 12-14. Steps 12-2 through 12-14 perform a component copy operation. A component move includes two additional steps, namely steps 12-6 and 12-8, in which the original component is deactivated and removed, respectively.

Further security issues The above-described DOCN architecture and signalling methods provide no explicit data confidentiality or integrity schemes. If either is needed, a secure connection between DOCN nodes or component homes must be set up. Confidentially is also strengthened by using the capability-based access for restricting a client's access. If better confidentiality is needed, the compo- nents should be designed accordingly.

References

1. Gruber, Tom: "What is an Ontology?", available at www-ksl . Stanford . edu/kst/what-is-an-ontology. html

2. General ideas and definitions, see www. ontology. org

Claims

1. A method for service collaboration between a new service (81) and an existing service (82) in a distributed object component network (DOCN) in which services are implemented as sets of one or more service components (3c - 3m; 71 - 76); c h a ra cte rized in that the method comprises the steps of: the new service (81) registering itself (8-0) with a service repository (SR); the new service (81 ) advertising its existence (8-2) via a communi- cation channel (NC); the communication channel (NC) reporting (8-4) the existence of the new service (81 ) to the existing service (82); the existing service (82) requesting (8-8) and obtaining (8-10) details of the new service (81) from the service repository (SR); the existing service (82) connecting (8-14) to the new service (81 ); whereby the existing service (82) can make use of the new service (81) without restarting the existing service (82).

2. A method according to claim 1 , ch a ra cte rized in that the communication channel is a notification channel substantially in accordance with CORBA specifications.

3. A method according to claim 1 or 2, ch a ra cte ri ze d in that the service repository (SR) comprises an ontology database (OD) containing an ontological description of services and that the step of requesting/obtaining (8-8, 8-10) details of the new service comprises an inquiry into the ontology database.

4. A method according to any one of the preceding claims, ch ara cte rized by authenticating a client (CT, C1 - C4); assigning one of several predetermined roles (R1 - R3) to the client (CT, C1 - C4) on the basis of the authenticating step; associating each role (R1 - R3) with a set of access rights to the service components (3c - 3m; 71 - 76) or sets (3A, 3B) thereof, the service components or sets implementing the service; whereby the client does not have to be authenticated in respect of individual service components or component sets thereof.

5. A method according to claim 4, characterized in that the step of assigning the role comprises providing the client with an object refer- ence to a component (RP) holding the role.

6. A method according to claim 5, characterized in that the object reference expires automatically after a predetermined lifetime.

7. A method according to claim 5 or 6, characterized in that the object reference is an object reference substantially in accordance with CORBA specifications.

8. A method according to any one of claims 4 to 7, characterize d in that the step of authenticating the client comprises mapping the client's (CT) identifier in an external data network (AN, DN) to a unique identifier in the distributed object component network (DOCN).

9. A method according to claim 8, characterized by concealing the unique identifier from entities outside the distributed object component network (DOCN).

10. A method according to any one of the preceding claims, characterized by forming a group of clients with similar access rights and as- signing each client with an identifier of the group.

11. A method according to claim 1, characterized by receiving (4-2; 5-6, 5-8; 6-14) a service request from the client; on the basis of the service request, providing the client with the requested service, the providing step further comprising: - accessing a service factory (SF);

- the service factory determining the set (3A, 3B) of service components (3c - 3m; 71 - 76) required to implement the service;

- the service factory preparing (4-4, 5-16, 6-24) the set by locating existing service components or by instantiating new ones.

12. A method according to claim 1, characterized by storing descriptions of the services in an ontology database (OD); and the service providing step further comprising sending an inquiry into the ontology database.

13. A method according to claim 12, c h a ra cte rized by providing the client with a software agent (PE) for cooperating with the ontology database in order to provide the client with additional services related to the service indicated by the service request from the client.

14. A distributed object component network (DOCN) in which each service is implemented as a set (3A, 3B) of one or more service components (3c - 3m; 71 - 77): c h a ra cte ri zed by a plurality of nodes (11) for executing the service components; a communication channel (NC); a service repository (SR) for locating a service indicated by a service request from a client (CT, C1 - C4); one or more service factories (SF) for determining and preparing the set (3A, 3B) of service components (3c - 3m; 71 - 76) required to implement the service located by the service repository (SR) such that: a new service (81 ) is adapted to:

- register itself (8-0) with a sen/ice repository (SR); and

- advertise its existence (8-2) via the communication channel (NC) to an existing service (82); the existing service (82) is adapted to: - request (8-8) and obtain (8-10) details of the new service (81 ) from the service repository (SR); and

- connect (8-14) to the new service (81); whereby the existing service (82) can make use of the new service (81) without restarting the existing service (82).