Service oriented platform architecture for a wireless network

Described is a framework system residing on a network including a plurality of services, wherein each of the services registers with the framework system, a service manager to manage each of the services which register with the framework system, the management including lifecycle management for each of the services and a communication broker to manage communication between the plurality of services.

INCORPORATION BY REFERENCE

U.S. patent application, entitled “Integrated Management of a Wireless Network,” filed on an even date herewith is assigned to the Assignee of the present application and is expressly incorporated herein, in its entirety, by reference.

BACKGROUND INFORMATION

Wireless networks are deployed in a great number of industries such as retail environments, transportation and logistics, manufacturing, warehousing, etc. These wireless networks may include large numbers of mobile units, wireless switches and access points. To maintain these networks routine tasks such as component roll-outs, updates, maintenance, support, etc. need to be performed. However, as the networks grow, the performance of these routine tasks becomes unwieldy. This may become a barrier to growth and result in the underutilization of the wireless network.

SUMMARY OF THE INVENTION

A framework system residing on a network including a plurality of services, wherein each of the services registers with the framework system, a service manager to manage each of the services which register with the framework system, the management including lifecycle management for each of the services and a communication broker to manage communication between the plurality of services.

Furthermore, a method including starting a first and second service by a service manager, instantiating the first and second service by registering the first and second service with a framework, the instantiating including generating a configuration file for each of the first and second services, wherein the configuration file includes a listing of interfaces for each of the first and second services, the configuration files being accessible to a communication broker and providing access to one of the interfaces of one of the first and second services by the other one of the first and second services via the communications broker.

In addition, a network appliance having a framework system for managing operations of a network on which the network appliance resides, the framework system including a plurality of services, wherein each of the services registers with the framework system, a service manager to manage each of the services which register with the framework system, the management including lifecycle management for each of the services and a communication broker to manage communication between the plurality of services.

DETAILED DESCRIPTION

The present invention may be further understood with reference to the following description and the appended drawings, wherein like elements are provided with the same reference numerals.FIG. 1shows an exemplary network1including a wireless network which may implement an exemplary embodiment of the present invention. The network1includes a network appliance10, a network server20, an access point30and a wireless switch40. Each of these devices are shown as interconnected via a wired portion of the network1. However, those of skill in the art will understand that these devices may also be wirelessly connected to the network1. In addition, network1may also include any number of additional network components and/or devices (not shown).

FIG. 1also shows mobile units31-33wirelessly connected to the network1via the access point30. The mobile units31-33may be any type of computing or processor based device such as desktop or laptop computers, personal digital assistants, mobile phones, pagers, scanners, etc. The mobile units31-33and access point30may operate within any type of wireless networking environment, e.g., Wireless Local Area Network (“WLAN”), Wireless Wide Area Network (“WWAN”), etc. Communication between the mobile units31-33and the access point30may be accomplished using any wireless protocol such as IEEE 802.11, Bluetooth, etc. Similarly, mobile units41-43are wirelessly connected to the network1via the wireless switch40. Those of skill in the art will understand that the network1is only exemplary and that the exemplary embodiment of the present invention may be implemented on any network which includes a wireless portion.

The owner of the above described exemplary network or any other network including wireless devices faces a variety of issues in operating and maintaining the network in its optimum state. Examples include that the owner of the network1may desire to add new devices, e.g., mobile units, access points, wireless switches, etc. The owner may desire to ensure that each of the mobile units includes the same version of software applications or update the applications on the mobile units.

Furthermore, the owner may desire to diagnose and resolve network problems either locally or remotely, e.g., slow response time. More effective monitoring would also allow the owner to diagnose problems before they occur so that they can be prevented. A host of other issues also arise such as the possible intermittent connectivity of mobile devices, security, application development, etc.

The exemplary embodiment of the present invention allows the owner of the network to address all of these issues and a variety of other issues relating to wireless networks by providing the owner with a centralized management system for the wireless network. The exemplary embodiment of the present invention provides a service delivery framework architecture for an enterprise mobility system which allows for any number of centralized services to be integrated into the framework architecture. The exemplary embodiment also allows these services to inter-communicate allowing a system administrator to both monitor and control the wireless network and the individual devices on the network. The exemplary embodiment of the system architecture will be described as residing on the network appliance10of the network1. However, those of skill in the art will understand that the system architecture may reside on any of a variety of devices in the network1, e.g., network server20. Throughout this description the terms framework, architecture and framework architecture may be used to describe the exemplary embodiment of the present invention.

FIG. 2shows an exemplary embodiment of a framework architecture50. The exemplary framework architecture50includes a service manager51, communications brokers52-54and services55-59. In the exemplary embodiment the service architecture50may be built using Java and run on a Java Virtual Machine (“JVM”). However, those of skill in the art will understand that the service architecture of the present invention is not limited to Java implementations.

The service manager51manages all services55-59that register with the framework architecture50. The management of services includes the creation of services and lifecycle management such as start, stop, suspend, resume, initialize and dispose operations. The service manager51will also include the ability to add new services to the framework50and dispose old services from the framework50. Additional details on the service manager51will be provided below.

The communications brokers52-54will provide communication primitives for the framework50. The communication primitives may be used for interaction between the services55-59. The communication brokers52-54may also provide a mechanism to locate service interfaces by name. The exemplary embodiment shows three communications brokers52-54. However, there may be more or less brokers depending on the specific applications. Exemplary communications brokers may include a messaging broker (e.g., Java Messaging Service (“JMS”), a Java Naming and Directory Interface (“JNDI”), etc.

The services55-59may be any service that is applicable for the management and control of the wireless network1. There may be two general types of services—basic services and composite services. Basic services are those services which provide basic functionality for the framework50. Exemplary basic services55-59may include scheduling, configuration, logging, security, licensing, dependencies, etc. Composite services are those services which address the operational and business purposes of the network1and build upon the basic services. Examples of composite services include network device monitoring, network device remote control, alarms, network mapping, etc. Additional examples of composite services are provided in U.S. patent application, entitled “Integrated Management of a Wireless Network,” filed on an even date herewith.

A service may be considered a function that is well defined, self contained and does not depend on the context or state of other services. While each of the services55-59are self contained, multiple services55-59may communicate or coordinate their functionality. The services55-59are modular and may be plugged into the framework50as needed.

The network1ofFIG. 1may have numerous devices which are spread out over a wide geographical area making it difficult to manage the entire network. Thus, it is a great advantage to be able to manage the network1from a single remote location which is connected to the network. The network appliance10may include a system for such management of the network1. The system may be based on the framework50described above and include various services which a system administrator may use to perform the network management functions. Thus, the system on the network appliance10may provide the centralized location for the network management.

The system may receive information and attributes from each of the mobile units31-33and41-43in the network1. This transmission of attributes may be controlled by a software component on the mobile units. For a more detailed description of an exemplary software component called a wireless agent, refer to U.S. patent application entitled “Integrated Management of a Wireless Network” filed on an even date herewith. However, the present invention is aimed at a framework architecture for the plugging in of services to be used to manage and control the wireless network and is not directly concerned with the mechanism for collection. The collection of attributes is merely included to provide an example of a business service that may be provided for the network.

FIG. 3shows an exemplary communication path between network devices. In this example the communication path is between the mobile unit31the access point30and the network appliance10. The communication path operates bi-directionally, i.e., the network appliance10may send messages to the mobile unit31and vice versa. The network appliance10is shown as including an Integrated Wireless Management (“IWM”) system60. This is the system which may be used to manage the wireless network. The framework50is the basis of including services for the IWM system60.

In the exemplary embodiment, each of the exemplary services55-59is an instance of a Java class. Each of the services55-59expose predefined interfaces for interaction by the service manager51.FIG. 4shows an exemplary service55which includes a set of predefined interfaces71-78. Each service55-59does not need to expose all the exemplary interfaces71-78. As will become apparent from the description of the exemplary interfaces71-78, some of these interfaces are required for the basic functionality of the service, e.g., starting the service. In addition, there may be other predefined interfaces which one of skill in the art may find useful for the lifecycle management of a service.

The following will provide a brief description of each of the interfaces71-78as relating to the service55. The specific Java class methods or other methods related to the exposed interface will be apparent to one of skill in the art based on the description of the interface71-78. The LogEnabled interface71will enable logging for the service55and will be implemented by those services which will use a centralized logging service. The Serviceable interface72will allow the service55to have access to the service manager51information and provides a service context for the service55.

If the service55needs to be configured using persistent configuration information, the service55will implement the Configurable interface73. This will provide a configuration object that maintains configuration information for the service55. The Initializable interface74will be implemented if the service55needs to allocate resources prior to becoming active. The initialization may include allocating any resources required throughout the service55lifecycle.

The Startable interface75is implemented for methods to start and stop the service55. The Suspendable interface76is implemented if the service manager51has the ability to suspend operation of the service55. Methods to suspend and resume the service55will be associated with the Suspendable interface76. For example, the service manager51may suspend the service55before updating resources upon which the service55depends.

The Reconfigurable interface77will be implemented when the service55may be reconfigured, i.e., the configuration is updated. Finally, the Disposable interface78is implemented by the service55if it holds resources to dispose of the service55at the end of its life. Thus, the service manager51will call the dispose method to release and destroy any resource that the service55owns at the end of its service life, i.e., the service55is stopped and will not be used anymore.

Each of the these interfaces71-78and any other required or optional interfaces may be implemented by the service manager51. Thus, as described above, the service manager51may create new services by allowing the individual services to inherit these interfaces from the service manager51. The individual services55-59will include the various methods to implement the functionality provided by the service, e.g., logging function, deployment function, etc., but these generic interfaces71-78which allow each service to be plugged into the framework50may be inherited from the service manager51. The service manager51will also instantiate each of the services55-59into the framework50including any dependencies for the service55-59. The instantiation of services will be discussed in more detail below.

While there is no specific requirement for the flow of events for a service,FIGS. 5-7provide exemplary flow paths for a service which implements all of the above described interfaces71-78.FIG. 5shows an exemplary path for a service in a startup phase100, i.e., instantiation of a service. The service manager51will access the appropriate methods for the interfaces. In a first step105, the service manager51will enable logging for the service by accessing the LogEnabled interface71. The service manager51will then provide the service context by accessing Serviceable interface72in step110. The service will then be configured using the Configurable interface73in step115. The service is then initialized using the Initializable interface74in step120. Finally, the service manager51will start the service using the Startable interface75in step125. At the completion of the process100, the service has been instantiated and started within the framework50.

FIG. 6shows an exemplary path for lifecycle management of a service during an operational phase130, i.e., normal operation between startup and shutdown. The service manager51may suspend the service using the Suspendable interface76in step135. While the service is suspended, the service may be reconfigured using the Reconfigurable interface77in step140. The service manager51may then resume the service using the resume method which is also part of the Suspendable interface76. The operational phase130refers to those lifecycle management operations which may be taken by the service manager51with respect to the service. Those of skill in the art will understand that during normal operations, the service may perform all the features and functionality associated with the service.

FIG. 7shows an exemplary path for a service in a shutdown phase150. In step155, the service manager51may stop the service using the stop method of the Startable interface75. In step160, the service manager51may release all the resources being used by the stopped service and dispose of the service if the service will not be used again. The dispose method is accessed via the Disposable interface78. Thus, at the end of the process150, the service has been removed from the framework50and all the resources allocated to the service have been released.

Thus, the above described how the service manager51controls the lifecycle of each of the services which are plugged into the framework50. Any service which implements the above described interfaces or their equivalents can be managed by the service manager51and therefore be used within the framework50to provide a service or set of services to a system administrator that is managing the wireless network1.

The following is a brief description of some exemplary basic services that may be plugged into the framework50. The described services are only exemplary and those of skill in the art will understand that there are numerous composite services that may be plugged into the framework50to provide a system administrator with functionality to manage and control the network1. The first exemplary basic service is a scheduler service which may provide a facility for threads to schedule tasks for future execution in a background thread. The scheduler service may schedule tasks for one time execution or for repeated execution at regular intervals.

The scheduler service may be based on the Timer and TimerTask that are part of Java version 1.3. The Timer provides the ability for other services to schedule tasks, while the TimerTask forms the base for tasks created by other services. Each Timer object will have a corresponding background thread that is used to execute the timer's tasks in sequential order.

As described above, for the scheduler service and for all the other exemplary services described above, the service manager51will create and instantiate the service into the framework50which will include inheriting some or all of the exemplary interfaces71-78described above. This allows the service manager51to manage the lifecycle of the service scheduler as described above.

Any other interfaces exposed by the scheduler service relate to the functionality of the scheduler service. In this example, the scheduler may expose a PreconfiguredSchedule interface which allows consumer services to add tasks to be executed. A DynamicSchedule interface may also be exposed which allows a consumer service to both add a task and schedule the task.

A second exemplary basic service is a heartbeat service which provides functionality for services to monitor themselves for failures. The heartbeat service may provide a feature for services to be continuously monitored or for ad hoc management. The scheduling of these tasks may be performed by the scheduler service. A service that desires continuous monitoring will implement a heartbeatable interface which allows for the creation of a monitor thread when the service is started and checks that the service is alive at configurable intervals. The ad hoc monitoring may be performed by a service prior to engaging in a time consuming task.

A third exemplary basic service is a logging service which provides the ability for services to log events. The logger service provides a client API that forms an abstraction layer over various implemented logging libraries, e.g., JDK 1.4, Apache's Log4J, etc. Any service which needs a logger instance will implement the LogEnabled interface71. The logging service will then use the libraries to record the events as required and save the events to, for example, a file, a database, etc.

A fourth exemplary basic service is a configuration service which is responsible for persisting and retrieving service configurations. A configuration object will describe the different parameters associated with the configuration of a service. The configuration service allows services to store and retrieve configuration parameters.

Other exemplary basic services include a deployment service providing a centralizes service archive deployment management capabilities. Licensing services for providing centralized license management across services. Security services for enforcing security policies for service communications. Administration services for providing services to view and manage the services running in the framework50.

The exemplary services described above are basic services for the operation of the framework50. More complex services for the management and control of the network1may also be implemented. These services may include, for example, monitoring of mobile units, management of mobile units, monitoring access points, diagnostic operations for the network, etc. The U.S. patent application entitled “Integrated Management of a Wireless Network” filed on an even date herewith, which is expressly incorporated by reference herein, provides examples of additional functions for monitoring and controlling the network1.

The various services which are plugged into the framework50may communicate and use the services offered by other services. The framework architecture50allows this to be accomplished by maintaining dynamic connections within the framework50.FIG. 8shows an exemplary process200for creating the dynamic connections within the framework50. The process200will be described with reference toFIG. 9which illustrates a sample flow of the dynamic connection process on the components within the framework50.

In step205, the service manager51starts the service55. The service manager51may be configured to start the services to be included in the framework50in a specific order. This order may be stored, for example, in a configuration table of a database accessible by the service manager51. In this example, the service manager is configured to start the services in the order55,56,57,58and59. As described above with reference toFIG. 5, the service manager may start the first service55by accessing the methods exposed by the service55such as configuration and initialization.

In step210, each of the services which are instantiated in the framework50will be registered. A naming service component is responsible for the registration of each of the services. The naming service is a basic service used for the purpose of this registration. Each of the services may be registered in the file65as shown inFIG. 9. The services are registered using a “serviceName” specified in the configuration file of the service. The “serviceName” may be used as a lookup key to locate an instance of the service. As described above, the service manager51, as part of the instantiation of the service, will call the configurable interface73in order to properly configure the service. Thus, a configuration file will be associated with each service. This configuration file will include the “serviceName” for the service and will be registered when the service is instantiated.

The file65may be, for example, an XML file which contains a listing of the various parameters which will be stored for each service that is instantiated into the framework50. The file65may also be a series of files or linked lists which contain the parameters. The information which will be described in this example may also be stored in other manners, e.g., database, table, etc. As will be described below, the only requirement for the storage of the parameters is that the parameters become searchable when they are stored.

In the next step215, an interface list is generated for each of the registered services. The communications broker52accesses the configuration file for each of the registered services to determine the interfaces for each of the services. As described above each service may be a producer meaning that it has the capability of exposing interfaces to other services. Each service may also be a consumer meaning that it can consume interfaces exposed by other services. A service may be a producer and/or a consumer. The communication broker52has access to each of the configuration files for the services in order to know what each service is producing and consuming. This access allows the communication broker to provide other services access to the registered interfaces. This will be described in greater detail below.

In step220, the process will determine if there are any other services which will be started. If there are additional services, the process continues back through steps205-215where the next service is started, registered and an interface list is generated. If there are no additional services to be started, the process continues to step225to determine if any services have been removed from the framework50. As described above, when services are no longer needed they may be removed or disposed from the framework using the disposable interface78. If a service is disposed, the process continues back to step210where the service is removed from the register list and to step215where the interface lists for the removed service is also deleted.

As part of the instantiation of a service, the communications broker52may also maintain a list of dependencies for each service. Thus, as described above, the exemplary heartbeat service is dependent on the exemplary scheduler service. The communications broker52will maintain this dependency and will not remove the scheduler service if the heartbeat service remains operative.

Thus, at the end of the process200, the communication broker52has produced a current listing of all the started services and the producer and consumer interfaces for these services. Those of skill in the art will understand that the process200is an ongoing process that occurs continuously throughout the run-time of the framework50and the file65is updated as services are started and disposed.

FIG. 10shows an exemplary dynamic connection270that is maintained during run time by the communication broker52. In this example, it may be considered that services55and56have been instantiated into the framework50by the service manager51. The communications broker52has access to the producer and consumer interfaces for the services55and56.

Those of skill in the art will understand that interfaces are exposed by objects. The interfaces are used for other objects to access methods which are contained in the object. The interfaces themselves are neither producers or consumers, but the service produces interface implementations for other (consumer) services, i.e., it provides a service or an output to other services, and/or a consumer of a service, i.e., it requires an input or a service from another service. In this description, interfaces are referred to as producer and/or consumer interfaces. These terms are used to refer to the producer outputs of the service or consumer inputs for the service.

For example, the service55may indicate that it needs the particular input258and the communication broker52will determine the matching output from another service by searching the file65. The search may be performed by first locating the service provider instance by the given name of the service, e.g., serviceName described above. The found service is then asked to provide an interface instance for the given configuration provided by the consumer service configuration. In this example, the communication broker will find the interface output261of the service56and indicate to the service55how to access the interface261to be provided with the proper input. thus, the communication broker52maintains the dynamic connection270during runtime to allow the services55and56to operate in concert.

Thus, the communication broker52may be considered a centralized wiring service which allows the various services that are plugged into the framework50to communicate. The communication broker52makes the dynamic connections as the services are added and deleted from the framework. Using the above described framework50, new services may be deployed during runtime and the service manager51and communication broker52work to integrate the new services into the framework. The framework is therefore open and expandable because any new services which are developed may be plugged into the framework50.

Furthermore, the exemplary embodiment has been described with respect to a single framework50residing on the network appliance50. Multiple framework architectures may be distributed throughout various devices on a network, e.g., multiple network appliances, network servers, etc. The above described framework architecture will allow the various services that are plugged into each framework to communicate because each framework will include the communication broker generated file containing the interfaces for each of the instantiated services.

For example, a framework resident on a first device may communicate its existence to a framework on a second device. The instantiated services on the second device may communicate with the instantiated services on the first device through the communication broker on the first device to determine if the services on the first device have any information needed by the services on the second device. Thus, services may be distributed throughout the entire network, but a system administrator on any particular device will have access to all the services of the network because of the framework architecture scheme according to the exemplary embodiment of the present invention.

The present invention has been described with the reference to the above exemplary embodiments. One skilled in the art would understand that the present invention may also be successfully implemented if modified. Accordingly, various modifications and changes may be made to the embodiments without departing from the broadest spirit and scope of the present invention as set forth in the claims that follow. The specification and drawings, accordingly, should be regarded in an illustrative rather than restrictive sense.