Patent Application
20090067600
The present invention discloses a method and an arrangement which provides high availability and robustness to services running on service execution platform, and uses external sources to fulfil the information need for the service (e.g. weather forecast delivered by MMS).
Today it is common that end users subscribes to services for use/deliverance to their handheld devices such as their mobile phone or their PDA. These services may typically be positioning services, weather services or any other information service. In the following the wording VAS, value added service, will be used for these kind of services delivered to handheld devices.
Today a typical VAS service uses service components external to its own service execution environment. The VAS service then typically, subscribes for information provided by the external service. If one of these external service components is malfunctioning, it puts the overall service out of order. For this invention to be applicable we assume that there exist several external service components that can provide the requested information. Typical examples of such services will be weather forecast, share prices, map data, route planning, etc.
An example is a weather forecast service that gives the user the weather report at the user's current location. This service forwards the mobile subscribers position to the weather forecast service, which returns the weather forecast in the requested area. If the weather service is out of order, the overall service cannot fulfil its execution.
The problem today is that there is no mechanism that ensures availability of VAS services independent of external service components. Although some of the problems are addressed in the below referenced patent publication it does not ensure a satisfactory combination of robustness, availability and implementation simplicity.
WO 20004925 describes a solution that chooses distribution channels based on a comparison of identifiers with reference values. However it does not describe any kind of well functioning pinging between a numbers of third part service providers such as positioning providers hence there is no mechanism ensuring that the needed components are fulfilling the needed quality of service.
Further it is known that BEA Weblogic one of the main providers of application servers on the market has a product BEA Weblogic Integration in their product portfolio specifically targeting business integration. By use of controls it is possible to access remote service components exposed as a Web service.
Thus from the discussion above it should be obvious that there is a need for a method that provides high availability and robustness to services running on service execution platform, and uses external sources to fulfil the information need for the service.
The features as defined by the independent claim enclosed characterize this arrangement and method.
In particular it is disclosed a method for providing high availability and high robustness for services running on service execution platforms, specified in the step of categorizing external service components according to their service types, such as weather and/or position services, where the method further comprises at least one of the following steps: registration of all the external service components into a list of objects representative of their type of service, and sending from a service platform a heartbeat function for checking and registration of the current status of the service components.
Further it is disclosed a communication arrangement adapted to provide high availability and high robustness for services running on service execution platforms, comprising service components categorized according to different service types, such as weather and/or position, specified in that the arrangement further comprises:
In order to make the invention more readily understandable, the discussion that follows will refer to the accompanying drawing.
In the following the present invention will be discussed by describing a preferred embodiment, and by referring to the accompanied drawings.
Today's VAS solutions often use service components outside its own execution domain. Thus the service chain is jeopardized if invoked service components are unreliable. The present invention solidifies the entire service environment by registering all available external components and generalising them into “service classes”. Hence, e.g. all positioning providers or all weather-report providers are put under the Class Position and Weather respectively. Heart-beat and status checks in combination with a certain degree of service redundancy ensure that the best-available service component under each class is invoked, leading to optimal service chain reliability and, in the end, to a higher QoS for the end user.
The core of the present invention is in an intelligent way to combine many providers of one and the same type of service, with service health-checks i.e. what is the present status of these services.
Among its main technical features is its mechanism that robustifies VAS services independently of unreliable service components.
The invention is implemented as a software update of the service execution environment.
In the following a first preferred embodiment of the invention will be described, with reference to the accompanied drawings.
As indicated in the previous section the solution to the problems created by the unstable service providers were to firstly, take advantage of the redundancy among the services provided by service providers, secondly to implement a mechanism that in an efficient way is polling or pinging each and every of the service providers for their health.
A more detailed description of the control/health check mechanism will be given in the following as will the principle of redundancy by way of example.
All external service components will be registered in this mechanism, and generalised into an abstracted service class. E.g. imagine the weather forecast companies “First Weather Service” and the “Second Weather Service” both will be members of the service class WEATHER. The mechanism will also contain a heartbeat function that checks whether the service components (e.g. First Weather Service) are alive. The current status of the service components will be registered.
The overall services will consist of service classes such as WEATHER, POSITIONING and many more, and it will not take into consideration which actual components are accessed. The overall service will get a reference to a functioning service component fulfilling the functional requirements from the overall service. If, for example, First Weather service is out of order, the overall service will get a reference to another registered component in the requested WEATHER service class (e.g. SECOND weather service).
shows the different domains involved in the context of the invention (end users, telecom operator, and 3rd party service providers), and where a VASRobustifier (a service broker) resides. The end user will typically access a service in the telecom operator's service platform, and the service platform will use the VASRobustifier to ensure that the VAS services use well-working service components provided by either internal or external service providers.
Feil! Fant ikke referansekilden. shows the architecture of an operator network. The VASRobustifier will in such a picture typically reside in the Application Server nodes (typically based on J2EE or .NET technology) indicated by the circle on the service layer.
The other process described in Figure is usage of the VASRobustifier to retrieve well-working service components. The ServiceBroker gets a request from a VAS service for a service component of type Weather. This request is forwarded to the ServiceClassList, which will return a reference to a working weather service component (in this scenario; First Weather Service). The same process is repeated for MMS and location.
The invention has thus, removed the subscribed services as a single point of failure. The VASRobustifier runs in an operator-controlled environment, and the probability that it fails will be much lower than the probability that one of the subscribed services fails. Hence, we have gained a better availability of the over-all service.
The mechanism can also be extended to support prioritisation of equal service components based on different parameters. E.g. one service component has historically better Quality of Services, is cheaper, more reliable data, etc. The health check process described above can be used to gather statistical data serving as a basis for the prioritisation task. The two boxes of the following figure shows an example where weather services are assigned priorities for instance based on response times.
Figure: Example of priorities assigned to weather services
Figure below describes the subscription procedure for the service components to the VASRobustifier.
All relevant data of the service components offered by the VASRobustifier mechanism are read in to the system at start-up. The ServiceClassList component will then use this information to create an instance of all ServiceClasses interfacing different service components.
The procedure will create an instance, a ServiceClass for each subscribed service component.
Distributed services may represent similar information in different ways. An example is that the SECOND Weather Service returns temperatures in Celsius degrees while the First Weather Service uses Fahrenheit degrees to indicate the same property. The ServiceClass responsibility is to map the set of properties of the subscribed service, e.g. the First Weather Service, to the set of VASRobustifier Weather properties.
Figure below shows a model of the main classes of the VASRobustifier and the relation between them. The use of abstraction, inheritance and association is the main driver of the realization of the VASRobustifier.
Figure shows a deployment diagram of the VASRobustifier. It will typically reside in an operator controlled domain and subscribe services that are in domains where the operator has no control. Although the invention does not specifically mention any access technology, the VASRobustifier will typically use Web Services both as a means of interacting with the subscribed service components and exposing its own interface. Further, the VASRobustifer may be implemented as a server component using component integration technologies such as Java Connector Architecture (JCA). This will make it easy to integrate the VASRobustifer into existing service platforms, as most of them are based on standardized technology such as J2EE.
The mechanism described above will robustify and increase QoS of VAS services dependant of external service components.
The invention hides the complexity of ensuring robust service quality for the overall service.
The invention provides a uniform way of providing high availability and robustness for heterogeneous service components.
The invention will provide high availability to services that normally uses unreliable service components.
In the previous sections the present invention has been described by way of examples, particularly an example using a health check mechanism as known from Java has been shown, however it is obvious that any mechanism that performs a polling process where the polling/pinging is sent from a sender to a number of services categorised into groups or classes according to their services, where the polling is effectuated between redundant services within separated classes or groups is possible. The use of checkCrowd and checkHeartBeat and the actor specific protocol is merely meant for making the present invention more readily understandable.
VAS Value Added Services
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/NO2005/000103 | 3/22/2005 | WO | 00 | 2/22/2007 |
