• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:

    公开号:BE1020876A3
    申请号:E201300836
    申请日:2013-12-12
    公开日:2014-06-03
    发明作者:Mattias Vanhoutte
    申请人:Televic Rail；
    IPC主号:
    专利说明:

    System and Method for Activating a Software Module Field of the Invention
    The present invention generally relates to the field of execution environments for electronically downloadable modules that are to be activated or deactivated. These modules can perform interactions with external systems and represent their current state.
    BACKGROUND OF THE INVENTION
    Solutions for providing management services to devices and local networks have been widely distributed and applied in recent years.
    A well-known standard that has been developed is the Open Service Gateway initiative (OSGi). OSGi is a set of specifications that define a modular component system. An implementation of those specifications results in the OSGi framework that creates a framework for developing application components. In OSGi, a basic component is known as an OSGi bundle. An OSGi application can be built from a combination of different bundles that can share a common functionality. The components in the framework are loosely linked and can communicate with each other by using services. In this regard, the OSGi framework makes it possible for developers to define dependencies between bundles, such as the packages and services required by the bundles. The OSGi framework can also determine whether a device has the necessary packages and services. In a typical implementation, a device running an OSGi framework with OSGi bundles can dynamically install, start, stop, update and uninstall OSGi bundles without having to restart the framework. By using another management program on the device, the functions of the OSGi bundles can also be controlled if the OSGi framework supports this. The bundles in the OSGi framework, for example, can be used to programmatically interact. If supported by the framework, the bundles can be managed by using a web or console-based tool.
    The OSGi environment is a framework that provides an execution environment for electronically downloadable modular components, called bundles. The framework includes a Java runtime engine, life cycle management, data storage, version management and one
    Service Register. Bundles can be Java applications, including classes, methods, and other resources that provide functions, or "services," to end users of a computer system and to other bundles. The OSGi technology provides a service-oriented architecture that enables bundles to dynamically discover each other to work together. Bundles are typically stored in a standard zip-based Java file format, or Java Archive file (JAR). OSGi bundles can be activated and deactivated in the OSGi environment without restarting the entire OSGi framework.
    However, software modules do not necessarily have to comply with the OSGi standard. There are various alternatives available. Impala is another dynamic modular productivity framework for Java-based web applications. Apache Felix or Eclipse Equinox and Knoplerfish are examples of open-source modularized software where the OSGi specifications are implemented in Java. However, the implementation of the OSGi specifications does not have to be limited to standard Java implementations. Other languages can also be used to implement OSGi specifications, for example C ++. Poco OSP, SOF, CTK, nOSGi and Celix are examples of implementations of specific C Or C ++ implementations of the OSGi specifications.
    One of the specific fields of application relates to client-server communication between a single fixed location-based off-boarder and transport vehicles (considered as clients), e.g., trains. A difficulty related to this environment is that it is often problematic to maintain a connection of acceptable quality long enough. A remote OSGi framework on for example a train can be updated (by downloading a specific OSGi bundle and starting this bundle) when there is a data connection between the mainland and the (moving) train. If the connection is of poor quality when the OSGi framework needs to be remotely updated, it may happen that a certain bundle cannot be activated in time.
    Solutions to various problems related to the deployment and / or maintenance of service modules have already been described, also in patent literature. Patent application US2004 / 194059 relates to the deployment of non-OSGi services or sources within an OSGi framework. The request proposes an "OSGilnstallBundle" class that allows non-OSGi sources, whether Java, specific code or other format, to be downloaded from a server and installed on a client system running on an OSGi framework. The OSGilnstallBundle class can be executed by a user or another bundle. The OSGilnstallBundle class manages non-OSGi resources by registering in the OSGi framework and calling a startup method.
    Patent application US2005 / 223101 is about solving necessary conditions for applications that use an OSGi framework. A specific application intended for a client device is packaged in an OSGi bundle, along with corresponding dependency information that identifies any necessary conditions that the application has to run correctly on the client device. It is then examined whether the client device meets the necessary conditions. If not, the necessary conditions are obtained and packaged in their own OSGi bundles (i.e. if they have not been packaged before). The various OSGi bundles that include the specific application and any required necessary conditions are then loaded onto the client device.
    There is therefore a need for a solution where software modules can be downloaded without necessarily being deployed immediately.
    Summary of the invention
    It is an object of embodiments of the present invention to propose a solution where a management software component can pre-download software modules and decide itself to (de) activate a particular module in the OSGi framework, even without a network connection. It is a further objective to provide a solution in which the activation or deactivation is configurable. It is a further objective to provide a solution in which the activation or deactivation is configurable by a self-describing module.
    The above object is achieved by the solution according to the present invention.
    In a first aspect, the invention relates to a method for activating or deactivating a software module on a client device. The method comprises the steps of: - loading the software module from a server to the host device, said software module comprising at least one configurable trigger imposing at least one necessary condition for activation or deactivation, - checking on the client device or on all necessary conditions are met, - activating or deactivating the software module if the checking step yields a positive result.
    In the proposed approach, there is indeed a clear separation between the download of the software module on the one hand and the actual (de) activation on the other. There can be a considerable period between the moment of download and the moment when the software module is actually used. To activate or deactivate the module, it is necessary that one or more conditions imposed by means of the configurable triggers are met.
    In a preferred embodiment, the software module is a self-describing software module. The self-describing software module is a virtual representation of the status of an external system. When activating the self-describing software module, interaction with the virtual module is translated into a number of specific commands that are executed on the client device and that are independent of the modular software framework.
    In a preferred embodiment, the step of checking becomes
    The invention also relates to a program executable on a programmable device that contains instructions that, when executed, perform the method as described above.
    In a further aspect, the invention also relates to a system for activating or deactivating a software module. The system comprises at least one client device and a server, said server being adapted to download to the at least one client device a software module that contains at least one configured trigger that imposes at least one condition that must be met to activate the software module or deactivate. The system comprises means for evaluating the configured triggers, said client device being further adapted to activate or deactivate the software module if evaluation of the configured triggers yields a positive result.
    The invention also relates to a transport vehicle comprising at least one client device that is adapted to receive a downloadable software module that includes at least one configurable trigger that imposes at least one necessary condition for activation or deactivation, said at least one client device further arranged to evaluate the configured triggers and to activate or deactivate the software module if said evaluation produces a positive result.
    In order to summarize the invention and the realized advantages over the prior art, certain objects and advantages of the invention have been described above. It goes without saying that all such objectives or advantages are not necessarily achieved in accordance with one specific embodiment of the invention. Thus, for example, persons skilled in the art will recognize that the invention may be embodied or embodied in a manner that achieves or optimizes one advantage or group of benefits as described herein, without necessarily realizing other goals or benefits described or suggested herein. .
    The above and other aspects of the invention will become clear and further explained with reference to the embodiment (s) described below.
    Brief description of the drawings
    The invention will now be further described, by way of example, with reference to the accompanying drawings, in which like reference numerals refer to like elements in the various figures.
    FIG. 1 illustrates a sequence diagram of a request to download a module from a server to a client.
    FIG. 2 illustrates an interaction between server and client with management module and trigger evaluation modules and an optional update module.
    FIG. 3 illustrates an interaction between server and client with management module and a missing trigger evaluation module.
    FIG. 4 illustrates a time diagram of Scenario 1.
    FIG. 5 illustrates a time diagram of Scenario 2.
    FIG. 6 illustrates a time diagram of Scenario 3.
    Detailed description of illustrative embodiments
    The present invention will be described with reference to specific embodiments and with reference to certain drawings, but the invention is not limited thereto, but is only limited by the claims.
    Moreover, the terms first, second, etc. are used in the description and in the claims to distinguish between similar elements and not necessarily for describing a sequence, either in time, in space, in importance or in any other way. It should be understood that the terms used are interchangeable under the proper conditions and that the embodiments of the invention described herein are capable of operating in sequences other than those described or illustrated herein.
    It is to be noted that the term "comprising" as used in the claims should not be interpreted as being limited to the means specified thereafter; it does not exclude other elements or steps. It must therefore be interpreted as a specification of the presence of the listed features, units, steps or components referred to, but it does not exclude the presence or addition of one or more other features, units, steps or components or groups thereof. Therefore, the scope of the expression "a device comprising means A and B" should not be limited to devices consisting only of parts A and B. It means that with regard to the present invention, the only relevant parts of the device A and B to be.
    References in this specification to "one embodiment" or "an embodiment" mean that a particular feature, structure, or feature described in connection with the embodiment is included in at least one embodiment of the present invention. Statements of the phrase "in one embodiment" or "in an embodiment" at different places in this specification do not necessarily all refer to the same embodiment, but it is possible. Furthermore, the specific features, structures or characteristics may be combined in any suitable manner in one or more embodiments, as will be apparent to those skilled in the art from this disclosure.
    In a similar manner, it should be noted that in the description of exemplary embodiments of the invention, various features of the invention are sometimes grouped in a single embodiment, figure, or description thereof to streamline disclosure and understanding of one or more of the facilitate various inventive aspects. However, this method of disclosure should not be interpreted as an expression of an intention that the claimed invention requires more features than expressly stated in each claim. As shown in the following claims, the inventive aspects lie in less than all the features of a single preceding disclosed embodiment. Therefore, the claims that follow the detailed description are hereby explicitly included in this detailed description, wherein each claim stands on its own as a separate embodiment of the present invention.
    In addition, since some embodiments described herein include some, but not other, features included in other embodiments, combinations of features of different embodiments are intended to fall within the scope of the invention and to form different embodiments, such as will be understood by someone skilled in this field. For example, in the following claims, any of the claimed embodiments can be used in any combination.
    It should be noted that the use of particular terminology in describing certain aspects of the invention does not imply that the terminology herein is redefined to be limited to any specific features of the features or aspects of the invention with which that terminology is associated.
    Numerous specific details are set forth in the description given here. However, it is understood that embodiments of the invention can be worked out without these specific details. In other cases, well-known methods, structures and techniques were not shown in detail in order not to obstruct the understanding of this description.
    The present invention proposes a solution to activate or deactivate an OSGi bundle on a remote OSGi framework. However, other examples where the same concepts for (de) activation are applicable can be found in Impala, another dynamic modular productivity framework for Java-based web applications. In general, the term "module" in this description refers to a software module (which can provide a particular service) and which is self-descriptive.
    A module in the context of this invention can be external firmware, external libraries, external content, an application framework, a framework library, or framework content. All these modules must be packaged in a valid OSGi bundle and must be transferred from an OSGi framework (server) for central management to a remote OSGi framework (client). For example, a module as external content may include media files that should be available on the client, a module as external firmware could be the binary file of an external application (which is active alongside the running OSGi framework), a module as an application framework could be an OSGi service for registering log information of other OSGi modules in the framework. All required resources for the module are bundled in a set of files (eg an archive). The set of files comprises at least one configuration file. For example, the archive can be a JAR file with a MANIFEST.MF file as the configuration file. The configuration file contains OSGi headers to create a valid OSGi bundle and is self-descriptive. The configuration file contains one or more configured triggers. The client's framework uses triggers to activate or deactivate a module. Only if the configured triggers for the module are met, will the module be (de) activated autonomously by the management module in the OSGi framework. Because the module is self-describing, the configuration file can contain information if the commands to be executed when the module is activated deviate from the standard behavior. The default behavior for example when activating a module can be installing and starting the module in the OSGi framework. An example of a deviating behavior can be that when activating a module with external content, this external content is extracted from the module, transferred to another machine in a private network with FTP, so that this content is available in a private network via a web server. In the modular OSGi framework, this is represented virtually because the module is active. In this way, the modular OSGi framework can create a virtual representation of the current state of the external systems connected to the modular framework.
    A client OSGi framework must be constructed as a combination of OSGi bundles that contains at least one OSGi bundle in order to be able to download and activate download of packaged OSGi bundles from a server according to the configured (de) activation configurations. This OSGi bundle is also optionally arranged for sending messages to the server OSGi framework. This OSGi management bundle is referred to in this description as "Management Module". In one embodiment, software for evaluating the configured triggers is available on the client device. This can be, for example, an assigned process on the client device that can evaluate a trigger of a particular module, e.g. by calling a web service. Alternatively, the OSGi framework may also contain one or more OSGi bundles that provide the functionality to evaluate one or certain possible (de) activation triggers for a downloaded OSGi bundle. This functionality can be available through a service in the OSGi framework. Such an OSGi bundle is referred to in the further description below as "trigger evaluation module". Optionally, the client OSGi framework can contain Update modules, these bundles can translate deviant behavior during (de) activation of a certain bundle into specific commands that must be executed. These bundles are optional because this deviant behavior is independent of the OSGi framework, but in some cases can be described therein.
    The software module is available on a server and must be deployed on a remote client. The remote client receives a request from the server to download the module from the server. Alternatively, the client can remotely launch a request to receive a download or the client can check regularly for new downloads. After downloading the module to the remote client, the module can be activated. To activate or deactivate a module, the framework evaluates configurable triggers of the self-describing module. A logical combination of triggers can be described in each module, preferably included in metadata. Such a combination of triggers can be an expression with logical AND operators, but can also include OR, XOR or NOT operators.
    Activation triggers (in the module metadata) are, for example: - an activation date: the module can only be activated after the activation date, - an external trigger: the module can only be activated if, for example, someone first presses a hardware button , - a dependency trigger: a trigger that indicates whether all (OSGi) dependencies (for example, libraries required in the running framework) of the module are present, - a rollback trigger: if an error occurs while the module is being activated, the last locked module is automatically reactivated, if this module exists.
    Examples of triggers for deactivation are: - a deactivation date: the module can only be deactivated after this date, - an external trigger: the module can only be deactivated if, for example, someone first presses a hardware button, - a version trigger: a trigger indicating that deactivation is only possible if a newer version of this module is available on the remote OSGi framework, - a lock trigger: the module is stored on the client's file system (and reused if a rollback occurs), - a reactivation trigger: while the module is deactivated, the last locked module is reactivated, if this module exists.
    Note that in addition to the above examples, other configured triggers (present in e.g. the metadata) can be used. Configuration of the triggers does not have to be limited to configuration by means of a configuration file for each module. For example, standard trigger configurations for each module can be accessed through a local database on the client. In certain embodiments, triggers can also add functionality to the framework. For example, when the rollback trigger is configured for a module, the framework solves the problem of reactivating the last locked module with the same functionality. Even without a data connection at the time of the defect, the functionality of the module is available in the remote OSGi framework. Later, when a network connection of sufficient quality is available, the server can be notified by a message that an error has occurred while activating the new module and that the last locked module has been reactivated. The data connection is not used to resend the last locked module because it was available on the client's file system.
    The self-describing module can describe the deviant behavior during (de) activation of the module on the basis of an Update module. The interaction with the virtual module in the OSGi framework is then each time translated into a number of commands that must be executed by the Update module on the relevant module. The state of the virtual OSGi module in the OSGi framework is then a representation of whether or not the corresponding commands have been executed.
    While in prior art solutions, activation or deactivation of a module can start as soon as it is received, in the present approach, a check is made of at least one configured activation trigger. Deactivation of the module is also carried out autonomously, based on at least one configured deactivation trigger. Only if all configured triggers in the metadata of the module are met, the activation or deactivation of the module can be performed in the OSGi framework.
    FIG. 1 represents a sequence diagram of an update of a module "X" from a server to a client device. It is assumed that the network connection between the server and the client is of acceptable quality. The server asks the client to download an updated module to the client (step 1). The client downloads the module from the server. It is assumed that the configuration is a MANIFEST.MF file in this example. After downloading (step 1.1), the management module searches the client in the configuration file for activation and deactivation triggers for the module. Optionally, the management module can also look for an update module for deviant behavior.
    1.2 The client management module checks each configured trigger by searching for the installed trigger evaluation module in the system. If the trigger evaluation module is installed, the client asks to validate the trigger with the downloaded module. If the trigger evaluation module cannot evaluate the trigger, for example because the module is not present in the system, the management module cannot activate the module. The client can inform the server about the missing trigger evaluation module. In step 1.2.1, the trigger evaluation module sends a response with the status of the configured trigger to the management module: the response confirms that the condition set by this trigger has been met.
    1.3 The client checks a second configured trigger. In 1.3.1, the trigger evaluation module sends a response with the status of the configured trigger: the response states that the trigger condition has not yet been met. In 1.3.2, the trigger evaluation module sends a response with the status of the configured trigger: the response confirms that the trigger condition has now been met. The trigger condition can be met by an external change (eg with a configured external trigger for activation: an external person confirms the start of the bundle by pressing a hardware button or with a configured trigger for activation time: the trigger condition will only be met when the activation time is over).
    1.4 The client has a network connection with the server and can send a message to inform the server that the first trigger has been met and that the second configured trigger has already been evaluated once but has not yet been met. With this message, the server knows that the required trigger evaluation module is installed on the remote OSGi framework, but the trigger has not yet been met.
    1.5 The client activates the module because all configured triggers have been met. Message 1.3.2 from the trigger evaluation module confirms that the second configured trigger is now also met.
    1.6 The client has a network connection with the server and can send a message to inform the server that all triggers have been confirmed and the module has now been activated.
    FIG. 2 illustrates a possible system to (de) activate an OSGi module according to an embodiment of the invention. The diagram shows the server, the client and some trigger evaluation modules for activation / deactivation on the client. Every trigger evaluation module is implemented here as a module in the system. By using separate modules for each trigger, it is possible to update the system with a new implementation of the trigger evaluation module with a new function. The trigger evaluation module can be installed with the system (and activated) to make a new trigger evaluation module available for future updates.
    An optional update module is also present in this figure. After all triggers have been validated, the client activates the module. In the standard case, the self-describing module is installed in the OSGi framework. Optionally, when activating the self-describing module, use can be made of a specific update module (1.5), this update module translates the deviant behavior during (de) activation of the module into specific commands that must be executed. The self-describing module contains the necessary information in the configuration file to use a specific update module. After this the client informs the server with the status of the triggers and the (de) activated module (1.6).
    FIG. 3 is a diagram on which dependence on the trigger evaluation module is not available to the client. The client wants to check this configured trigger for activation, but cannot find the trigger evaluation module. When there is a network connection with the server, the client informs the server about the missing module. The server can respond to this event by sending a request to download the required trigger evaluation module. Once the missing trigger evaluation module is installed and activated in the remote OSGi framework, the client can check all configured activation triggers.
    Illustrations of some possible application scenarios are now provided. Module M_1 is configured with activation triggers: activation trigger with activation date t0, a dependency trigger, a rollback trigger. The configured triggers for deactivation are: deactivation trigger with deactivation date t2, a version trigger, a lock trigger. Module M_2 is configured with triggers for activation: activation trigger with activation date t3, a dependency trigger, a rollback trigger. The configured triggers for deactivation are: deactivation trigger with deactivation date t4, a version trigger, a lock trigger.
    Scenario 1
    The module is received on time (downloaded) on the remote train, at tO: all dependencies of M_1 are present, so module M_1 is activated at tO.
    At t2, the version trigger is OK (M_2 is available (downloaded) on the remote client), so M_1 is activated due to the lock trigger, Module M_1 is stored on the file system before deactivation.
    At the same time (t2 = t3) all dependencies on M_2 are resolved, so module M_2 is activated (on time).
    Scenario 2
    The difference with the previous scenario is that M_2 could not start downloading in time due to poor network connection to the server. Therefore, the module is received too late on the remote train.
    On t2, M_1 is not deactivated because the version trigger indicates that there is no new module available on the remote client (M_2 has not yet been downloaded).
    At t5, the version trigger indicates that a new module is available, so M_1 is deactivated and locked. M_2 can also be activated on t5 (all triggers are met).
    Scenario 3
    The difference with scenario 1 is that at the time of activation of the new module M_2, an error occurs. The framework reactivates the old module (rollback to old situation).
    The conditions of the version trigger and deactivation trigger are met on t2, so M_1 is deactivated and locked.
    At the same time (t2 = t3) all triggers of M_2 are met, so M_2 starts to activate.
    At t6 an error occurs while activating M_2, so M_2 is not active. Due to the rollback trigger of M_2, the framework reactivates the last locked module (M_1). Due to the version trigger of M_l, M_1 remains active (there is no newer version available on the remote client).
    A specific use case for the railways is an update from a central server to a train (client) with a module (M_1) that contains content (data) about the train timetable and possible connections of the train (content bundle). This content can be activated during a period of, for example, 1 year. These modules can have a lock trigger for deactivation that the module stores on the train when it is deactivated, and a version trigger that deactivates the bundle when a new bundle is available.
    Due to train delays, the content can be updated for a short period of time with a new module (M_2). For example, module M_2 must be activated immediately (trigger for activation) and must be confirmed by the train crew by pressing a certain button on the train (external trigger). If the button is pressed by a member of the train crew, the module M_2 is activated.
    Due to the version trigger of module M_l, module M_1 is deactivated. Due to the locked trigger of module M_l, module M_1 is stored on the train before deactivation.
    Module M_2 can, for example, have two deactivation triggers: an external trigger and a reactivation trigger that reactivates the last locked module after deactivation (M_1). When the train is no longer delayed, a member of the train crew confirms deactivation of module M_2 in a rural area (without a network connection to the server). After deactivation of module M_2, module M_1 will be reactivated due to the reactivation trigger. All travelers had accurate information without a network connection on the train. When the train has a network connection with the server, the train (client) can inform the server that the last locked module has been reactivated.
    Although the invention has been illustrated and described in detail in the drawings and foregoing description, such illustrations and descriptions are to be considered as illustrative or exemplary and not restrictive. The foregoing description explains certain embodiments of the invention in detail. It should be noted, however, that no matter how detailed the foregoing is contained in the text, the invention can be made in many ways. The invention is not limited to the disclosed embodiments.
    Other variations on the disclosed embodiments may be understood and performed by persons skilled in the art and by practicing the claimed invention, through a study of the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps and the indefinite article "a" does not exclude a plural. A single processor or other unit can perform the functions of different items in the claims. The mere fact that certain measures are listed in mutually different dependent claims does not mean that a combination of those measures cannot be used to benefit. A computer program can be stored / distributed on a suitable medium, such as an optical storage medium or semiconductor medium supplied with or as part of other hardware, but can also be distributed in other forms, such as via the internet or other wired or wireless telecommunication systems. Any references in the claims should not be construed as limiting the scope.
    权利要求:
    Claims (11)
    [1]
    Method for activating or deactivating a software module on a client device, comprising the steps of: - loading said software module from a server to said client device, said software module comprising at least one configurable trigger that has at least one necessary condition for activation or requires deactivation, - checking on said client device if all of the aforementioned necessary conditions are met, - activating or deactivating said software module when said checking step yields a positive result.
    [2]
    The activation or deactivation method according to claim 1, wherein said checking step is performed in a module for evaluating said configured triggers available on said client device.
    [3]
    The activation or deactivation method according to claim 2, wherein said checking comprises requesting a validation to said module to evaluate whether said evaluation module is actually present on said client device.
    [4]
    The activation or deactivation method according to claim 3, wherein a step is performed wherein said client device informs said server when no evaluation module is available on said client device.
    [5]
    The activation or deactivation method according to claim 4, wherein said server responds to said informing step by installing the missing evaluation module.
    [6]
    The activation or deactivation method according to any of claims 1 to 5, wherein said configured triggers form a logical expression to be met.
    [7]
    The activation or deactivation method according to any of claims 1 to 6, wherein said at least one configured trigger is one of the following: a trigger with an activation date, a trigger with a deactivation date, a trigger indicative of a dependence on another module, a rollback trigger, a lock trigger, a version trigger, a reactivation trigger.
    [8]
    Method for activating or deactivating according to one of the preceding claims, wherein said software module is an OSGi module.
    [9]
    A program executable on a programmable device, comprising instructions that, when executed, perform the method according to any of claims 1 to 8.
    [10]
    A system for activating or deactivating a software module, comprising at least one client device and a server, said server being adapted to download to said at least one client device a software module that contains at least one configured trigger that imposes at least one condition to be met for activation or deactivation of said software module, said system comprising means for evaluating said configured triggers, said client device being further adapted to activate or deactivate said software module if evaluation of said configured triggers yields a positive result.
    [11]
    A transport vehicle comprising at least one client device that is adapted to receive a downloadable software module that includes at least one configurable trigger that imposes at least one necessary condition for activation or deactivation, said at least one client device being further configured to handle said configured triggers and to activate or deactivate said software module if said evaluation yields a positive result.
    类似技术:
    公开号 | 公开日 | 专利标题
    CN102413022B|2014-04-16|Application debugging method and system
    CN103283209B|2015-12-09|A kind of application service platform system and its implementation
    US8775577B1|2014-07-08|System and method for configuration management service
    US7509638B2|2009-03-24|Method and apparatus for providing a pluggable and extendable J2EE architecture
    JP4959715B2|2012-06-27|Web service compliance with updated contracts
    JP2014518425A|2014-07-28|Deploy test environments by making pre-built environments available instantly
    KR101219855B1|2013-01-21|Dynamic service surrogates
    US8522207B1|2013-08-27|Systems and methods for automated centralized build/merge management
    EP2107459A1|2009-10-07|A software appliance framework
    JP2018530070A|2018-10-11|System and method for building, optimizing and implementing a platform on a cloud-based computing environment
    US20100312879A1|2010-12-09|Plug-in provisioning integration in a clustered environment
    WO2009055751A1|2009-04-30|Translating declarative models
    US7437705B1|2008-10-14|System and method for building an application on a computing device which includes an environment-controlling process
    WO2012000999A1|2012-01-05|Configuring a computer system for a software package installation
    CN107608710B|2021-08-31|Software project construction task configuration method and device based on Jenkins tool
    US20110087767A1|2011-04-14|Computer Environment Analysis Tool
    CN107465709B|2020-09-01|Distributed mirror image construction task method, device and system
    CN105471968A|2016-04-06|Data exchange method, data exchange system and data platform server
    US10972538B2|2021-04-06|Synchronization of components in heterogeneous systems
    US20060248517A1|2006-11-02|Method and computer system for activation of source files
    BE1020876A3|2014-06-03|SYSTEM AND METHOD FOR ACTIVATING A SOFTWARE MODULE
    CN108228190B|2021-08-24|Persistent integration and delivery methods, systems, devices, and computer-readable storage media
    Hummel et al.2010|Automated creation and assessment of component adapters with test cases
    US20130254757A1|2013-09-26|Nesting installations of software products
    US9235437B2|2016-01-12|Method and integration component for integrating OSGi environments into a Service-oriented Architecture
    同族专利:
    公开号 | 公开日
    EP2746938A1|2014-06-25|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US6349408B1|1998-03-23|2002-02-19|Sun Microsystems, Inc.|Techniques for implementing a framework for extensible applications|
    US20040194059A1|2003-03-27|2004-09-30|International Business Machines Corporation|Method to deploy software using an open service gateway initiative framework|
    US20050223101A1|2004-03-22|2005-10-06|International Business Machines Corporation|Computer-implemented method, system and program product for resolving prerequisites for native applications utilizing an open service gateway initiative framework|
    US7739681B2|2005-06-29|2010-06-15|Novell, Inc.|Delayed application installation|US20140380341A1|2013-06-20|2014-12-25|Microsoft Corporation|Application activation using decoupled versioning|
    CN104850097B|2015-03-31|2017-06-16|中车青岛四方车辆研究所有限公司|Suitable for the data transmission method of the electric current loop gateway of gyrocar traction invertor|
    法律状态:
    优先权:
    申请号 | 申请日 | 专利标题
    EP12198170|2012-12-19|
    EP12198170.8A|EP2746938A1|2012-12-19|2012-12-19|System and method for activating a software module|
    [返回顶部]