WO2002057911A1

WO2002057911A1 - Dynamic service achitecture

Info

Publication number: WO2002057911A1
Application number: PCT/FI2002/000044
Authority: WO
Inventors: Jyri Lankinen; Mika LEPPÄNEN
Original assignee: Nokia Corporation
Priority date: 2001-01-22
Filing date: 2002-01-21
Publication date: 2002-07-25
Also published as: FI20010123A; FI20010123A0

Abstract

This invention relates to services provided in a communications network. The structure of the architecture comprises a container class. It receives events and selects, based on the event type, an appropriate handler for handling the event. The container also includes an optional method for loading service logic components from various places, such as a database. The container is preferably divided into a common part and a custom part. The custom part comprises service logic components. Connecting several components to-gether, it is possible to make large and complex services. The custom part also comprises a container context object that provides service instance specific data storage for the components of the service. The common part is similar for every event. It comprises interfaces for different types of events a control part for controlling the architecture, and a service context object, which contains service specific data. The common part defines the general behavior of the service.

Description

Dynamic Service Architecture

Field of the Invention

This invention relates to services provided in a communications network. Especially, the invention relates to the structures of services, how the services have been constructed, and how the services run.

Background of the Invention

Services can be constructed in many ways. All ways have their drawbacks and advantages. A situation can be that the service, which has been created, uses many complicated procedures, meaning that it is difficult to update, and it was tedious to create it. Often, complicated procedures are service specific, so it is very difficult or impossible to use them in another service. The procedures can also be quite static to use when constructing dynamic services. Further, it can be that the programming language used for writing the service is used in a non-standard way, meaning incompatibilities will occur with other versions of the language. The execution of the service may also need a special interpreter.

Java is an object-oriented programming language. For understanding the description of the invention, basic structures of the Java language should be kept in mind. An object is a software component that usually contains executive codes and data. In an object-oriented language actual objects are not defined, but classes of objects are defined. A class is a template for multiple objects with similar features. It can be said that a class describes all common features for all objects in the class. So, a single object is a concrete representation of the class, in other words an instance. The state of an object is the data of the object.

Methods are functions, i.e. executable codes that operate in a class or an object. A stream is a path of communication between the source of some information and its destination. Java contains several inputstream and outputstream classes for defining different streams. Serializing is a feature in the Java environment that makes it possible to save a state of an instance of the class (the concrete representation of a class) in the form of a byte-line. Serialized instances can be deserialized making it possible to use the saved class representation later. Threads are objects of the Thread-class. Preferably, the threads are used if the application runs several tasks simultaneously. A thread runs a task that is given to it. The task contains commands that the operating system accomplishes. Parallel threads run at the same time, i.e. the application can execute parallel commands individually, without waiting for the end of a single command before starting the next command. So, if there are several applications and/or tasks to be run simultaneously, it is useful to use thread- modeling.

To sum up, a Java application comprises classes, which refer to objects. One of the classes is the "route" class, which contains basic methods of the application and makes it possible to get the other classes that belong to the application.

The objective of this invention is to alleviate drawbacks of known solutions to create a service that is dynamic, and easy to construct and update. This is achieved in a way described in the claims.

Summary of the Invention

The objective of the invention is to offer an easy-to-perform service architecture. The structure of the architecture comprises a container class. It receives events and selects, based on the event type, an appropriate handler for handling the event. The container also includes a method for loading service logic components from various places, such as a database. The container is preferably divided into a common part and a custom part.

The custom part comprises service logic components. Connecting several components together, it is possible to make large and complex services. The connections among the components are defined when they are designed. At runtime the components, make decisions to set up the connections. A chain or network of components forms a handler for a specific event. The custom part also comprises a container context object. The container context provides service instance specific data storage (a run-time storage) for the components of the service. The common part is similar for every event. It comprises interfaces for different types of events, a control part for controlling the architecture, and a service context object, which contains service specific data. The common part defines the general behavior of the service, and controls executions of the service logic components. Brief Description of the Drawings

In the following the invention is described in more detail by means of Figures 1 - 3 in the attached drawings where.

Figure 1 illustrates an example of the service structure according to the invention,

Figure 2 illustrates examples of event handlers in the custom part of the service structure,

Figure 3 illustrates a flowchart describing a method how a service is created in the service structure.

Detailed Description of the Invention

Figure 1 shows an example of the service architecture according to the invention. Preferably, the invention is implemented by means of using Java. The core of the structure is a service logic program (SLOP), which is a container (a class) for other elements of the structure. The SLOP receives events and selects, based on the event type, an appropriate handler for handling the event. The container also includes a method for loading service logic components (4) from various places, such as a database. The SLOP is preferably divided into a common part (1 ) and a custom part (2).

The common part includes a common interface (3) for all types of events which the service handles. The amount of types and what they are depends on the service itself. For example, the types can be timeout, SLOP, IWU, ISC, Notification, or Signal. The timeout type carries timeout information of timers, which have been set concerning specific sen/ices, elements, and events. The SLOP type relates to initial functions and events concerning specific SLC (Service Logic Component) information. The IWU type relates to the events which come from a IWU unit (Inter-Working Unit) that is a bridge between the SS7 network and the CORBA interface used by the services. The ISC (Inter-SLOP Communication) type relates to communications among different SLOPs. The Notification type relates to changes in configuration and/or update information. The Signal type relates to mainly exceptional situations, such as "killing" the SLOP.

The common part is similar for every event. Further, the common part comprises a service context object (5), which contains service specific data, common for every element in the service architecture. The common part directs the events to the right handlers, i.e. to the right chain or network of service logic components (4). In other words, the common part of the SLOP controls executions of the components. The arrangement for this is called SLOP main loop or control part.

The custom part comprises service logic components (SLC). An SLC is a distinctive logic component object for handling a specific task or tasks. The SLC is reusable so the same component object may be used in many instances. The SLC comprises at least one pointer (or value), which indicates the next executable SLC. When an SLC is designed, it is possible to construct the logic so that depending on the state of the SLC (SLC is always in some state) the object-reference (a pointer) to the next executable SLC is chosen (in other words the pointer indicating the next SLC is chosen). By connecting several SLCs together, using the object-references of the SLCs, it is possible to make large and complex services, i.e. service instances. At runtime the components make decisions to choose the right object-reference. As mentioned, a chain or network of SLCs forms a handler for a specific event. However, it should be mentioned that SLC, which is the last in a chain of SLCs do not need comprise a pointer or pointers.

The custom part also comprises an initial SLOP context object, which comprises initial state information and a mapping part that contains initial pointers (values) to for every incoming event type, each pointer informing the first SLC for invoking. The initial SLOP context is used for keeping initial values, and is copied for forming a SLOP context that is used at runtime.

The SLOP context (copied) (6) directs an event incoming to the architecture to the SLC, which the control part invokes first for performing the desired service instance. In other words, the mapping part in the SLOP context uses the pointer that is allocated to this particular incoming event type. The SLOP context is updated during the execution of the service. In the mapping part, a field containing a pointer to the next executable SLC and the state information change, depending how the service progresses through SLCs (there can. be several fields for executable SLCs if the service instance receives several events). I.e. the SLOP context provides a service instance specific data storage (a run-time storage) for the SLCs of the service.

Each SLOP also has a SLOP state associated with it. The SLOP state specifies the state for the overall SLOP irrespective of which SLC has previously been executed. The SLOP state specifies the type of event or the types of events the SLOP is waiting for. Further, the state can specify whether a SLOP is in execution or not and whether it has been loaded to the primary storage. For instance, in a state called RUNNING, a SLOP has been started. In state WAITJWU the SLOP is waiting for external events from the interworking unit, which is further connected to an external telecommunications switch communicating with the SLOP. In state WAIT_ISC_REQ the SLOP is waiting for a message from another SLOP. Other states may exist as well.

Let's examine in Figure 1 an example of an execution, how internal operation of the service architecture works. An event for requesting a certain execution comes to the common part (1 ) through the common interface (3). Now, the common part is ready to checks the right handler from the SLOP context in the custom part. The SLOP context contains the information (the mapping part) which SLC is the first one for executing the event, and returns the object-reference (pointer, or value) of this SLC to the common part. I.e. the SLOP context in the mapping part directs the event to the SLC, which the control part invokes first.

Next, the common part calls (invokes) the object-reference of the first SLC to start to execute the service. The common part (the control part) controls that the first SLC starts to run. Further the control part relays service instance state information to the first SLC, which can make changes to the state information. After the first SLC has accomplished it's task/s, the call (control) is returned to the common part (to the control part), and the first SLC informs a new object-reference to the SLOP context. Now, the common part is ready to call the object-reference of the next SLC, named SLC 1 , from the SLOP context. The task of SLC 1 is to send a log message to a logging system. Depending on the success of the logging, the state of SLC 1 (and maybe the instance state information too) changes. If the logging succeeded, a new state defines the object-reference for the next SLC to point to SLC 3. If the logging failed, a new state defines (chooses) the object-reference for the next SLC to point to SLC 2. In other words, the SLC 1 chooses the pointer to indicate the next SLC for invoking. After finishing the logging, the SLC returns the call to the common part, and informs the SLOP context of a new object-reference, and also the instance state information changed. In the case of a successful logging, the common part (the control part) calls the object-reference for SLC 3 from the SLOP context. The common part starts SLC 3 to run. SLC 3 accomplishes certain queries. For example, it could load additional SLCs from a database and attach them to the logic chain. After completion of its tasks, the state of SLC 3 has changed. SLC 3 informs the SLOP context of a new object-reference of the next SLC, named SLC 4 and changed instance state information, and also returns the call to the common part.

The common part starts SLC 4 to run. SLC 4 accomplishes invocations, for example to some external system through some standard protocol. After completion of its tasks, the state of SLC 4 has changed. SLC 4 informs the SLOP context of a new object-reference of the next SLC, named SLC 5, and changed instance state information, and also returns the call to the common part. SLC 5 is the last SLC in the handler chain. SLC finishes the service, and returns the call to the common part.

In the case of a failed logging, the common part calls the object- reference to the SLC 2 from the SLOP context. The common part starts SLC 2 to run. SLC 2 accomplishes an error message (7) to the SLC 1. After completion of its tasks, the state of SLC 2 and also the state of SLC 1 have changed. SLC 2 informs the SLOP context of a new object-reference of the next SLC, named SLC 5, and changed instance state information, and also returns the call to the common part. SLC 5 is the last SLC in the handler chain. SLC finishes the service, and returns the call to the common part.

Figure 2 shows examples of what kind of handlers the custom part can contain. The set of handlers can be different than in Figure 2. The set used depends on the SLOP itself, and what it needs. The SLOP context contains service instance specific information, such as state information and object reference information. Further, the SLOP context comprises a mapping part, which directs an event incoming to the architecture to the SLC, which the control part invokes first for performing the desired service instance. When a specific event is desired to be executed, the SLOP context (according to the mapping part) returns the object reference that contains the pointer information (value) of the first SLC, for instance First SLC in Figure 2 (21), of the relevant handler to the common part that controls the whole execution of the event. Let's follow the handler that starts from First SLC (21) in Figure 2. After when First SLC (21) has accomplished it's task/s, the call is returned to the common part, and First SLC informs the SLOP context of a new object- reference, and changed instance state information. Now, the common part is ready to call the object-reference of the next SLC, named Logic SLC 1 (22), from the SLOP context. Logic SLC 1 does the required task/s, and depending on the success, the state of Logic SLC 1 changes. If the task was succeeded, a new state defines (chooses) the object-reference to point to Logic SLC 2 (23). If the task failed, a new state defines the object-reference to point to Error SLC (25), Logic SLC 1 returns the call to the common part, and informs the SLOP context of a new object-reference, and changed instance state information.

In the case of successful completion of a task, the common part calls the object-reference to the Logic SLC 2 (23) from the SLOP context. The common part starts Logic SLC 2 to run. Logic SLC 2 accomplishes certain queries. After completion of its tasks, the state of Logic SLC 2 has changed. Logic SLC 2 informs the SLOP context of a new object-reference to the next SLC, named End-of-Service SLC (24) that is the last SLC in the handler chain and changed instance state information, and returns the call to the common part.

In the case of failed completion of a task, the common part calls the object-reference to the Error SLC (25) from the SLOP context. The common part starts Error SLC to run. Error SLC accomplishes an error message (26) to Logic SLC 1. After completion of its tasks, the state of Error SLC and also the state of Logic SLC 1 have changed. Error SLC informs the SLOP context of a new object-reference to the next SLC, End-of-Service SLC, that is the last SLC in the handler chain and changed instance state information, and returns the call to the common part. .

Abort SLC (27) relates to, for instance, timeout events when a timer setting directs to the service in use to be aborted. End SLC relates to the procedure used for ending the service. End SLC, such as other SLCs also, is a common block which can be used for performing the ending procedure of any event (or service). End SLC can direct the ending procedure to a more specific ending SLC, such us End-of-Service SLC (24) in Figure 2. Cancel SLC (29) contains cancel procedure for canceling an SLC action. Async ISC SLC 1 (210) and Async ISC SLC 2 relates to communications among different SLOPs. The communication between the SLOPs can be synchronous or asynchronous. The mentioned SLCs relates to asynchronous communications. Timeout SLC (212) relates to timeout events. Signal SLC 1 and Signal SLC 2 concerns signal events.

Different handlers may work together. For instance, if Logic SLC 1 (22) runs a logging task, and is waiting for the response, the timeout period may pass. Due to this the SLOP receives a timeout event that is directed to Timeout SLC (212), which registers the timeout event concerning Logic SLC 1. After the registration, the common part of SLOP directs Abort SLC to abort the function of Logic SLC 1. After the abort, the common part ends the original event using End SLC (28). As can be noticed, there can be many different ways to handle events. However, it is effective, and reasonable to use handlers (SLCs) which are designed to do common tasks for many services and instances, i.e. it is reasonable to use reusable SLCs.

Figure 3 shows an example of the method according to the invention. The first step (31 ) is to load the objects that are needed for accomplishing the service, if the objects have not already been loaded. It is possible to store objects elsewhere than in a class environment (SLOP) which offers the actual place for performing the service. A natural place for storing objects is a special database in a network, which services all around the network can use. However, the components needed can also be already stored in the service architecture.

The next step (32) is to direct an event coming from the client (In this context, the client can be an actual end-user of the service, another SLOP, a service logic component, or a special element in a network, for instance.) to the right SLC (object) which starts the execution of the desired service. So the event can be thought to be a command or inter-command for performing the service. The common part directs the event to the right SLC based on the object-reference given by the SLOP context in the custom part. The SLC executes its tasks.

The next step (33), if needed, can be directing the execution of the service to the next SLC (object). As mentioned before, the service is made up of a chain or network of SLCs. The chain can be only one SLC or several SLCs. The construction of the chain is formed in real-time, when the SLCs of the service chain execute their tasks. A state of the SLC in turn changes in running-time, which means that the object-reference used for identifying the next SLC may change also. In this way, the service constructs itself dynamically. The directing step can be repeated (34) as many times as required for accomplishing the service.

Finally, the last SLC executes its own tasks and the SLOP performs the required procedures for ending the execution of the service (or the event that was used for performing the service) (35).

It is worth mentioning that SLCs can be stored as serialized objects comprising object specific instance data, and that SLCs, which make a difference only between different variable values, forms different instances of the same object class.

Using the service structure according to the invention, it is convenient to construct services, and also to update them. Since a single SLC can decide internally which SLC is the next for performing the service, the common structure of SLOP is generic and can be used for many different services. Taking these matters into account, it is evident that the invention can be used in many other solutions, than described in this text, in the scope of the inventive idea.

Claims

1. A service architecture implemented by an object-oriented programming language characterized in that the architecture comprises: a common part comprising common data for each service instance, that the architecture can perform; a custom part comprising instance specific data for each service instance; at least one component object for performing a desired service instance; and a control part for invoking said component objects.

2. An architecture according to claim 1, characterized in that each component object comprises at least one pointer, amongst which the component object determines a pointer for the next component object to be invoked at runtime.

3. An architecture according to claim 2, characterized in that several component objects forms at least one network of the component objects in such a way that the determined pointer of each component object indicates the next component object which is in turn for invoking.

4. An architecture according to claim 1, 2, or 3, characterized in -that at least two of the component objects with different variable values forms different instances of the same object class.

5. An architecture according to claim 2, 3, or 4 characterized in that the custom part comprises instance specific data for directing an event incoming to the architecture to the component object, which the control part invokes first for performing the desired service instance identified in the event, and containing initial state information.

6. An architecture according to claim 5 characterized in that the instance specific data further comprises at least one pointing part indicating to the control part the determined pointer, which indicates the next component object for evoking.

7. An architecture according to claim 6 characterized in that the instance specific data further comprises service instance state infor- mation, which the control part relays to the component object, which is in turn for invoking.

8. An architecture according to claim 1, 2, 3, 4, 5, 6, or 7 c h a r- a c t e r i z e d in that the component objects are stored as serialized objects comprising object specific instance data.

9. An architecture according to claim 1, 2, 3, 4, 5, 6, 7 or 8 characterized by a container class performing a foundation for the service architecture.

10. An architecture according to claim 1, characterized in that at least one component object determines the next component object to be invoked next for performing the desired service instance.

11. An architecture according to claim 1 characterized in that the instance specific data comprises at least one pointer indicating to the control part the component object to be invoked next for performing the desired service instance.

12. A method for accomplishing a service that a client desires, formed by using an object-oriented programming language, characterized in that the method comprises the steps of

- directing an event coming from the client to the right component object for starting the execution of the desired service,

- directing the execution of the service to the next component object, if needed,

- repeating the directing step to the next new component object, if needed, and

- finishing the execution of the service when the last component object needed to accomplish the service has finished it's tasks.

13. A method according to claim 12, characterized in that the method further comprises the step of loading the right objects, if needed, to the service structure for accomplishing the desired service instance.

14. A method according to claim 12 or 13, characterized in that the directing and the repeating steps use a value of a pointer in the component object for the directing.

15. A method according to claim 14, characterized in that the pointer of the component object depends on the state of the component object in a way that when the state changes, the pointer to the next compo- nent object changes, pointing to a different next component object than before the change of the state.

16. A method according to claim 15, characterized in that during the execution of a single component object, necessary changes in desired service instance data are updated.