Patent Application
20090077546
This invention relates to the implementation of software development platform, more specifically, a method, apparatus and their systems that are capable of implementing non-function logic extensibly and independently of function logic.
One of the major causes for the current commercial applications being not flexible enough lies in the inseparable and unmanageable tangle of function concerns and non-function concerns, wherein the function concerns refer to commercial functions and logics while the non-function concerns refer to the aspects such as performances, security, monitoring, and extensibility. For the program codes, the crosscutting of function concerns and non-function concerns increases the complexity significantly and results in difficulty in comprehension, construction, expansion, and reuse, for example:
Consequently, just as the still more detailed explanation presented as follows, the separation of concerns becomes the major targets and path for modern software technologies including AOP (Aspect Oriented Programming) and J2EE (Java™ 2 Platform Enterprise Edition Specification) etc. However, utilization of these technologies is confronted with extreme restraint. On the one hand, AOP can only process simple NFR tasks such as log. On the other hand, even though container is introduced into J2EE such that the latter may process complicated NFR issues (for instance, transaction), it is generally time consuming to add such NFR supports, and it also requires adequate understanding of container implementation and relevant skills. It is fairly difficult to implement customization support and specialized NFR support in the current J2EE containers, resulting in a fact that only some general NFRs are supported in J2EE, with the remaining NFRs still mingled with the function codes.
AOP is a programming paradigm that was presented in 1990s by Xerox PARX Company. AOP enables the developer to separate the concerns. Many non-function services such as log, security inspection, and transaction management etc. are thus separated from function services. Moreover, function services may share these non-function services. In case non-function behavior varies, these function services require no amendment, and only the non-function services require amendment.
According to the results of investigation conducted by AOSD (Aspect-Oriented Software Development, relevant reference is available in the Internet website aosd.net), there are approximately 100 kinds of AOP implementation. For AOP implementation based on Java, there are over 20 kinds of implementation. Several kinds of relatively mature AOP implementation are hereby listed as follows:
1. AspectJ
AspectJ (trademark) (relevant reference is available on Internet website eclipse.org under aspectj) is a type of general aspect-oriented extension of Java. Prior to being disposed, AspectJ may conduct weaving while compiling. AspectJ is a type of static weaving that utilizes pre-compiler to enhance the source codes. AspectJ is a type of mature AOP implementation, however, it is very complicated and requires special-purpose Java compiler.
2. AspectWerkz
AspectWerkz (trademark) (relevant reference is available on Internet website aspectwerkz.codehous.org) is a type of dynamic AOP framework. AspectWerkz may modify Java byte codes in order to implement aspect weaving. Weaving takes place in two different phases, of which, one phase is class loading phase, and the other is activating phase.
3. SpringFramework
SpringFramework (trademark) (relevant reference is available on Internet website springframework.org under documents/wiki/Spring AOP Framework) is a type of AOP framework based on dynamic proxy, in which the dynamic proxy comes from proxy design mode. Dynamic proxy need not generate proxy for each active service object. It has to fulfill proxy generating for the interfaces and proxies to be activated, and the runtime will generate proxy object. SpringFramework uses as default the proxy mechanism provided by JDK.
4. JBoss AOP
JBoss AOP (trademark) (relevant reference is available on Internet website jboss.org under products/aop) uses Javassist to modify the byte codes so as to implement dynamic weaving during class loading.
For the known AOP implementation, the non-function portion (aspect) is still programmed with codes. The respective aspects and function codes are woven together in runtime or compiling to generate hybrid codes. Therefore, each aspect will be loaded into the memory with function code. If several function codes use one aspect and these function codes are all in the memory, the memory may have several copies of the aspect. Besides, no plug-in framework is utilized for providing AOP implementation of extension mechanism for aspect.
For instance, in some application containers of J2EE (Java™ 2 platform enterprise compiling specifications v1.4) container (relevant reference is available on the javasun website), some non-function portions that the application programs utilize frequently are separated and provided by container. At present, J2EE container supports the non-functions including authentication, transaction, and log etc. However, current J2EE does not provide extension mechanism and framework in order to allow a third party to extend these non-function services implementations and weave them into applications.
In a book titled as “Lightweight plug-in-based application development” published in 2002 by Mayer et al., plug-in concept was put forward as a design mode (the design mode described in the book adopted the form put forward by a book titled as “Design Patterns: Elements of Reusable Object-Oriented Software” published by Gamma et al. in 1995), and exemplary implementations in Java were given. Its architecture includes the plug-in managers of loading classes and identifying the classes that utilize reflection to implement the known interfaces as main interface, and its relevant contents are presented detailedly in a technical report titled as “The Reflection API” published by Green et al. in Sun Microsystems, Inc. in 1997-2001, which is available on the javasun Internet website under docs/books/tutorial/reflect. The exemplary implementations proposed by Mayer et al. allow utilization of multiple plug-ins and different interfaces to extend a certain application, however, it fails to mention that plug-ins may be added to other plug-ins.
PluggableComponent provides a mode of infrastructure or architecture that allows component exchange at runtime, and relevant contents are presented detailedly in an article titled as “Pluggable Component—A Pattern for Interactive System Configuration” published by Völter in EuroPLoP'99 in 1999. Characteristics of the architecture lie in registry for managing PluggableComponent of different types. The registry provides the administrator through configuration tools with a list used for configuring available components for his applications.
Eclipse platform was designed for constructing an integral development environment, its relevant contents are presented in detail in a technical report titled as “Eclipse Platform Technical Overview” published by Object Technology International, Inc. in July 2001, and the article is available on the eclipse.org Internet website under eclipse-overview. Eclipse platform is based on the mechanism that is utilized to find out, integrate, and run the components that are referred to as plug-ins. Any plug-in may define freely new extension points (relevant descriptions are also available on the above-mentioned website) and provide new API for other plug-ins. Plug-in may extend the functions of other plug-ins and extend the kernel. This provides flexibility in creating still more complicated configuration.
However, all these plug-in frameworks function on application layer. User request gives the designator that shows which plug-ins should be included in order to meet the request. However, in application containers, information on which non-function plug-ins should be invoked may not be given directly in only the user request.
In the USA patent application filed by Gupta et al. and published as No. US2007/0124797A1 on May 31, 2007, a method to create, manage, and execute policy in network service environment and a system for applying the system are disclosed, and these intended to separate functional logic from non-function logic as well. The system includes policy manager, policy executor, clients, and services. Client includes the software for requesting the services. The services indicate network services such as log-in application or operable (functional) process, and the interfaces and encryption of messages. Policy manager is applicable to designated functions such as log, authentication, encryption, and cache etc., which are not core commercial logics but provide non-function contribution really. Policy manager is used in separating commercial concerns from non-commercial concerns. Policy executor is used in monitoring and executing the policy that are configured by policy manager. Policy manager is implemented in the application layer of OSI (open system interconnection) 7-layer model in the system, and the created policies are executed in the lower layers. No modification is made to lower layers of the network in the system. In the system, policy may be implemented as message interceptor, so the policy may be introduced into the message flow path seamlessly. Or, policy may be deployed into the gateway and service proxy. Gateways and proxy may intercept messages in order to implement corresponding policy. According to the above-mentioned contents, it is obvious that the system disclosed in the patent application utilizes policy manager to configure and meet the non-function demands, however it fails to provide an extensible method to allow the developer to extend and customize the supports for non-function demands. Besides, the method disclosed in the patent application locates the policy manager between client and backend services, only the access to service interfaces can be controlled in fact, the control of access between multiple services requires adding multiple policy manager accordingly, resulting in higher complexity of network implementation and higher implementation cost and time consumption.
Therefore, the existing technologies need a mechanism that allows easy, quick, and extensible separation of functional logic from non-function logic.
To solve the above-mentioned problems of the existing technologies, this invention puts forward a method, apparatus and system thereof as well as computer program products that can implement non-function logic extensibly and independently of function logic.
To achieve the above-mentioned objective, the present invention provides a method of implementing non-function logic extensibly and independently of functional logic, comprising: acquiring association relationship between a policy and a required plug-in based on a loaded policy demand configuration; generating a plug-in context definition according to the acquired association relationship, the plug-in context definition being part of a plug-in context associated with the plug-in, wherein the plug-in context defines services provided by the plug-in and reference to other plug-ins related to the plug-in; and generating a plug-in context object based on the plug-in context definition, wherein the plug-in context object is an instantiated plug-in context definition.
To achieve the above-mentioned objective, the present invention also provides an apparatus of implementing non-function logic extensibly and independently of functional logic, comprising: an application loader for loading policy demand configuration of an application; a policy attacher for acquiring association relationship between a policy and a required plug-in based on the loaded policy demand configuration, and for generating a plug-in context definition according to the acquired association relationship, the plug-in context definition being part of a plug-in context associated with the plug-in, wherein the plug-in context defines services provided by the plug-in and reference to other plug-ins related to the plug-in; and an application builder for generating a plug-in context object based on the plug-in context definition, wherein the plug-in context object is an instantiated plug-in context definition.
To achieve the above-mentioned objective, the present invention also provides a system for separating functional logic from non-function logic and implementing the non-function logic, including: an application layer entity configured to implement functional logic by user and utilize plug-ins provided by an infrastructure service plug-in layer entity; the infrastructure service plug-in layer entity configured to implement the plug-in by utilizing services provided by an application runtime layer entity; and the application runtime layer entity configured to implement the methods as claimed in any one of claims 1-9 for invocation of the infrastructure service plug-in layer entity.
To achieve the above-mentioned objective, the present invention also provides a computer program products that include the program codes stored in the storage media of computer, and the program codes may be executed so as to implement the method according to this invention.
According to the preferred embodiment of the present invention, abstract layer is provided for the supplier of infrastructure service, the non-function logic of the application is separated from the functional logic of application, the non-function configuration of the application can be modified flexibly, requiring no re-compilation or re-deployment of the application.
According to preferred embodiment of the present invention, runtime constructor may be somewhat modified to add some runtime extension points, for instance the extension points before or after creating component Instance: Before(After)CreatingComponentInstance, and the extension points before or after invoking service method: Before(After)InvokingServiceMethod etc. In fact, most infrastructure services such as log, security, and transaction etc. are active during the time period of these runtime extension points. In other words, extension of these extension points may implement most infrastructure services.
According to preferred embodiment of the present invention, policy (non-function demand) registry and/or plug-in registry is introduced in. Policy registry may store the policies supported by the plug-ins, while the plug-in registry stores the relationships between plug-ins and maintain relationship among plug-ins, for example extension relationship and/or dependency relationship.
According to the preferred embodiment of the present invention, modify the loading process of the application so as to map the policy configuration of the application to the dependency relationship of plug-ins. In addition, the acquired dependency relationships of plug-ins are stored the plug-in context entity, wherein the plug-in context entity is attached to corresponding runtime object of the application. In this way, it is possible to locate directly the depended-on plug-ins, without querying the policy registry and plug-in registry in execution of the application.
According to preferred embodiment of the present invention, the application's functional logic may be separated from its non-function logic easily, quickly, and extensibly.
Besides, according to preferred embodiment of the present invention, relevant plug-ins may be invoked directly when the application is executed, without querying the registry for location; the operating performance is therefore improved.
As compared to AOP technology, the present invention allows to hold a global view of application such that complicated policy of transaction may be implemented. Moreover, the infrastructure service for policy could be developed in an extensible way.
As compared to the policy in the current application container (Java for example), the present invention allows development of infrastructure service in an extensible way, and only the J2EE container supplier may modify or extend the infrastructure service in the current application container.
Compared with traditional extension mechanism, the present invention enables implicit invocation to infrastructure service plug-ins in terms of application configuration.
With the aid of detailed description in conjunction with the attached figures, the present invention will be comprehended more easily, wherein the same reference numbers in attached figures indicate the same elements, and in the attached figures:
In the following, the system architecture of the present invention is described by referring to
As shown in
Application runtime layer includes two sublayers, namely the application runtime core sublayer 117 and infrastructure service plug-in framework sublayer 115.
The application runtime core sublayer 117 includes the following parts: application loader 127, application builder 129, and application constructor unit 131. Application builder 129 generates runtime objects for components of the application and linking between components. In the application bootstrap period (namely period of preparing for operation), application builder 129 is utilized. Application constructor unit 131 is used in creating component instance or establishing communication between component instances. In the application's running period, application constructor unit 131 is utilized. The above-mentioned parts are provided with the functions known to those ordinary skilled in the art, they are somewhat modified to implement the present invention; wherein, application constructor unit 131 is modified to add runtime extension points such as BeforeComponentInstanceCreation and AfterComponentInstanceCreation etc., of which the runtime extension point refers to the extension point to be invoked by application runtime core sublayer 117. It is obvious according to the reference to Eclipse that extension point means a certain point provided in application, and a third party may utilize the point to add its own functional modules in application to extend its existing application. Application loader 127 is modified to invoke the policy attacher 125 that will be described below, the policy attacher 125 may query the plug-in registry as described below based on the policy demand configuration from application loader 127 to map the application's policy configuration to the supported plug-in. Application builder 129 is modified so that it not only generates application runtime object, but also generates interrelated plug-in context according to the input from policy adapter. The so-called plug-in context includes the services offered by the plug-ins and invocation of other plug-ins related thereto.
The infrastructure service plug-in framework sublayer 115 includes the following: plug-in registry 121 and policy attacher 125. Alternatively, policy registry 119 and policy matcher 123 may be included. Policy registry 119 stores policies supported by plug-ins and relationship between the policies, for example the policy containing relation, such as individual identity authentication including password authentication, fingerprint authentication, and iris authentication etc. In fact, policy registry 119 defines policy capability that the system supports. Plug-in registry 121 stores information on relevant plug-ins and relationship between plug-ins. These relationships include the extension relationship and/or dependency relationship between plug-ins, for example. According to the present invention, policy attacher 125 may directly query plug-in registry 121 and map the application's policy configuration to the supported plug-ins, and return association relationship between the policy demand configuration and the supported plug-ins. In such a case, the definition of policy demand configuration must be nailed down to each individual plug-in, in other words, the entry of plug-in registry should be defined still more specifically, and this may be relatively complicated and relatively time consuming. According to an preferred embodiment of the present invention, policy attacher 125 may transfer the definition of policy demand configuration to the policy matcher 123 first, and the policy matcher 123 may thus analyze and find out the required policy, and query policy registry 119 to determine whether or not the architecture of the system supports the required policy configuration. If yes, it will correspondingly query plug-in registry 121 and acquire the association relationship (namely handle) between policy and plug-in, and send it to the policy attacher 125. In such a case, the system running efficiency may be enhanced, and the bootstrap time may be reduced.
In accordance with the acquired association relationship, policy attacher 125 may generate plug-in context definition of the application, including the association (namely handle) with the plug-in instances and send it to the application builder 129.
Infrastructure service plug-in layer includes all types of service plug-ins developed by the infrastructure service developer on the basis of the non-function logic provided by application runtime layer and provided for the application layer, such as transaction 107, security 109, log 111, and other service plug-in 113. The other service plug-in 113 may be any plug-in that may implemented on the application runtime layer. These service plug-ins may be implemented by expanding the runtime extension points.
Application layer includes various applications that the user (for instance, the software developer) intend to implement, such as Airline Mileage and credit card points exchange system 101, on-line game 103, and other application 105. The other application 105 may be any application that requires to invoke the service plug-ins provided by the infrastructure service plug-in layer. When user implements the application on a platform based on the present system architecture, the functional logic will be implemented in the application layer, and the infrastructure service plug-ins will be invoked via the runtime extension point defined in application constructor unit 131 according to policy demand configuration so as to implement the non-function logic. With combination of functional logic and non-function logic, the application intended by the user can be implemented finally.
Besides, it is allowed to further define extension points in the plug-in that point to other plug-ins to implement further functions. As above-mentioned, the relationship between plug-ins includes extension relationship and/or dependency relationship, and the relationship is also stored in the plug-in registry 121. Certainly, other relationships between plug-ins may be defined if necessary. Herein, the extension relationship between plug-ins indicates that other extension points may be provided in a plug-in, and the extension point can be extended only when a certain conditions are satisfied. Dependency relationship indicates that instantiation of a plug-in in runtime depends on the implementation result of another plug-in. Examples will be given in the following to explain the two types of relationships between plug-ins.
In step 202, the user defines functional logic and policy demand configuration on a platform based on the system architecture of the present invention, and load them into the memory. The user may define function modules in any programming language on any programming platform; for instance, the user may program function modules in Java language on Windows™ development platform, with a statement made where needs to invoke non-function module, in other words, the demand description should be given.
In step 204, application bootstrap process is conducted in memory. Specific execution process of step 204 will be described detailedly in the following.
In step 206, application constructor unit 131 is utilized to extend the extension point generated in step 204 in runtime, in other words, injection point of plug-in is invoked, and instances of corresponding plug-ins are created in runtime so as to execute corresponding function.
Information flow 1 includes component function of the application and policy demand configuration defined separately according to function demand and non-function demand;
Information flow 2 includes component functions of the application defined according to function demand;
The information flows 3, 4, and 5 include the policy demand configuration information defined according to non-function demand, which may be in the same or different forms in application loader 127, policy attacher 125, and policy matcher 123 as necessary.
Information flow 6 includes the association relationship between the acquired policy and the supported plug-in, such as the description and handles of plug-in required for implementation of non-function;
Information flow 7 includes the plug-in context definition, which is part of the plug-in context related to the plug-in; the plug-in context defines the services provided by the plug-in and reference of other plug-in associated thereto.
The information flow 8 includes application runtime objects, plug-in context objects, and their association.
In the following, the application bootstrap process in the system architecture according to the present invention is described by referring to
In step 402, application loader 127 loads component function definition and policy demand configuration of the application into the memory, in other words, deploy the application package into the application runtime. The so-called application runtime indicates that the application package had been loaded into the memory, here the application package is already in “ready” mode and allows invocation at any time.
In step 404, application loader 127 generate component definition (namely functional logic module) according to component function definitions and transfer the policy demand configuration to policy attacher 125 and then to policy matcher 123; in such a process, the policy demand configuration may have different forms as required.
The loading of component function definition of the application and generating of component definition may be fulfilled by using the existing technologies; for example, the application running which uses the running environment Tuscany of SCA (Service Component Architecture) as a basic layer may be implemented; therefore the detailed description is omitted herein. In addition, the above-mentioned process is unnecessary for implementing the objects of the present invention.
In step 406, policy matcher 123 queries the plug-in registry 121 on the basis of policy demand configuration to acquire the supported plug-ins for the policy demand configuration, and return association relationships between the policy and the required plug-ins (including the plug-in description and handle) to the policy attacher 125. Alternatively, in step 406, policy matcher 123 queries policy registry 119 first so as to find out whether or not the system supports the required plug-ins. If so, it will query plug-in registry 121 and return the association relationship between the policy and the required plug-ins; otherwise, it will return the instruction for abnormality.
In step 408, according to the received description and handle of the plug-in, policy attacher 125 generates plug-in context definition for the plug-in; the plug-in context definition is part of the plug-in context related to the plug-in; wherein, the plug-in context defines the service provided by the plug-in which is associated with the handle of the plug-in, and the reference of other plug-ins related to it; of which, the plug-in context may be formed as chain table, tree-shape structure, or any other structures known to those ordinary skilled in the art.
In step 410, application builder 129 generates application runtime objects on the basis of component definitions, generates plug-in context objects on the basis of plug-in context definitions, and associates the plug-in context object with corresponding application runtime object; wherein, the plug-in context object is a instantiated plug-in context definition.
In the following, we'd take the on-line payment system as an example to explain the referential implementation of the present invention. In this referential implementation, SCA (Service Component Architecture) runtime environment Tuscany may be utilized as application runtime environment for the basic layers. Here simplified pseudo codes are utilized so as to illustrate the following mechanism better. Given as typical example, infrastructure service plug-in “log” may be implemented in infrastructure service plug-in layer shown in
1. Modification of application runtime core sublayer 117
Modification of the application runtime core sublayer 117 includes the modification of application constructor unit 131, application loader 127, and application builder 129. The following pseudo codes for the modification are underlined.
First of all, to allow the application runtime to be aware of the Paypal component's demands for log and thus invoke “log”, the runtime application loader 127 “ComponentLoader” should be modified as follows to create plug-in context definition:
The method “ComponentLoader” will parse application configuration and identify some key words such as “demand”. Key word “demand” is used for designating the intended infrastructure service (intent). Method “processListofIntent” may invoke policy attacher 125 to generate corresponding plug-in context definition.
Secondly, the application builder 129 i.e. “JavaComponentBuilder” should be modified as follows to associate the plug-in context and corresponding component:
Finally, to ensure runtime being extensible, the runtime extension points in runtime application constructor unit 131 should be indicated. In order to implement the extension point activated before invoking service “BeforeInvokeServiceMethod”, the extension point “BeforeInvokeServiceMethod” should be declared before acquiring component instances and invoking its service; afterwards, when implementing application constructor unit 131, the extension point “System.BeforeInvokeServiceMethod” extended by all plug-in should be find out from the plugin context acquired by application builder 129, release links to each plug-in, add its sub-plug-in context and run the plug-in. The following shows the modification of service invocation class “PojoTargetInvoker”
//Activate all plug-ins extending this extension point
public void processBeforeInvokeServiceMethod (object payload,
{
With the method “processBeforeInvokeServiceMethod”, plug-in context of current component instances may be acquired. According to the context, acquire the reference “e” of plug-in “log”, which extends the extension point “BeforeInvokeServiceMethod” and then invoke “log”. Notice that the invocation of “log” occurs before service invocation, operation.invoke( ).
2. Implementation of infrastructure service plug-in framework sublayer 115
The infrastructure service plug-in framework sublayer 115 includes the plug-in registry 121, policy matcher 123, and policy attacher 125. Alternatively, it may also include policy registry 119.
First of all, the plug-in registry maintains information of plug-in (for example, the provided policy) and relationship between the plug-ins (extension relationship and/or dependency relationship). The following shows the implementation of plug-in registry 121, which indexes plug-in according to policy and indexes plug-in according to extension points:
Plug-in class maintains the provided plug-in extension and extension point. The following shows implementation of extension of extension point in plug-ins and of the extension points providing plug-ins that have extension relationship and dependency relationship with the plug-in:
Secondly, the policy registry 119 maintains the mapping between demand and policy of infrastructure service, wherein, the policy describes some mutual capability or constraint that may be applied in the service components or between service components. The following shows the implementation of acquiring policy according to demands:
Thirdly, policy matcher 123 is responsible for finding out the supported plug-ins for demand. The following shows the implementation of acquiring policy according to demand and then acquiring plug-in according to policy:
Finally, policy attacher 125 generates the context definition of the supported plug-in for demand. Method “generatePluginContextDefinition” constructs plug-in context definition for plug-in, while the method “buildPluginContextChain” organizes the plug-in context definitions as chain table according to plug-in relationship, and returns the heading of the chain table. The above-mentioned method finds out all plug-ins according to each policy, finds out corresponding plug-in definition from plug-in registry 121, and establishes plug-in definition context.
Method “PluginContextDefintion” provides a modes to establish context tree for the required plug-in hierarchical structure.
3. Implementation of log plug-in
Plug-in configuration designates the extension points to be extended and the extension it provides. Here, the extension point “filter” that has extension relationship with “log” plug-in is given. The following shows the configuration of “log” plug-in.
Log service invokes relevant information by “Log” plug-in extending the extension point “BeforeInvokeServiceMethod”. The following shows the specific implementation of “log” plug-in.
4. Relevant codes and configuration of on-line payment system
The following shows pseudo codes of Paypal component provided with log codes.
With the “log” plug-in, log demand may be added simply to the configuration of on-line payment application such that the log codes may be deleted from the application codes. The following shows the configuration of on-line payment system, and the log demand is indicated with underline.
In the following, “log” plug-in will be taken as an example to show the extension relationship between plug-ins.
Assume that “log” plug-in provides the capability of creating log component instances and invoking service method. In addition, the “log” plug-in provides extension points “filter” so as to add filtering condition.
Moreover, plugin “ABC filter” may extend the extension point “filter” of plug-in “log” so that only the information conforming to “ABC” condition is logged.
In this example, the plug-in context stores the extension points, that is, extension point “filter”. In addition, the extension point “filter” points to another plug-in context which stores the extension “ABC filter” of the required extension point, in other words, it extends the extension point “filter” and requires plug-in “ABC filter” here.
In the following, the above-mentioned “log” plug-in will be taken as an example to show the dependency relationship between plug-ins.
Assuming that “monitor” plug-in exists and provides each identity with a capability of monitoring the creation of component instances and method invocation. Besides, plug-in provides service so as to acquire the number of current component instances of the selected identity.
At the same time, “resource management” plug-in provides a capability of limiting the maximum number of component instances of each identity. The plug-in supports “monitor” plug-in to acquire the current number of component instances before component instance is created for each identity.
Plug-in context stores the services provided and required by the plug-in. In addition, it also stores reference of dependency plug-in (namely the plug-in that provides the required service). In this example, service provided by the plug-in is to limit the maximum number of component instances, while the service it requires is extension point “monitor” to provide the number of current instances. The extension point “monitor” points to another plug-in context, and it stores the extension “monitor” of the required extension point, in other words, it extends the extension point “monitor” and requires plug-in “monitor” here.
The functions of each component in
Although the computer system described in
The present invention may also be implemented as a computer program products applied in the computer systems, for example, the one shown in
Many features and advantages of the present invention are apparent from the above description, and it is intended to cover all such features and advantages of the present invention by the appended claims. In addition, it will be understood by those ordinary skilled in the art that a lot of modifications and changes is possible, therefore it is unnecessary to limit the present invention to the specific construction and operation as shown and described. Hence all applicable modifications and equivalents may be considered to fall in the scope of the present invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| 200710153691.9 | Sep 2007 | CN | national |
