IEICE TRANS. INF. & SYST., VOL.E89–D, NO.4 APRIL 2006
1421
PAPER
Special Section on Kowledge-Based Software Engineering
A Flexible Connection Model for Software Components Hironori WASHIZAKI†a) , Member, Daiki HOSHI†† , Nonmember, and Yoshiaki FUKAZAWA††† , Member
SUMMARY A component connection enables a component to use the functionality of other components directly, without generating adapters or other mechanisms at run-time. In conventional component connection models, the connection between components, particularly third-party components, is very costly for code reuse because the component source code must be modified if the types of requester-side and provider-side are different. This paper proposes a new component model, built upon an existing component architecture, which abandons a component service type and connects components based on a method type collection of the provider and requester components. Our model enables flexible connections owing to relaxed component matching, in which the system that implements our model automatically converts values of parameters, return values, and exceptions between required methods and provided ones within a well-defined range. As a result of experimental evaluations, it is found that our model is superior to conventional models in terms of the component-use cost and the capability of changing connections. key words: component-based development, software components, connection model, software reuse, JavaBeans
1. Introduction Component-based software development (CBD) [1] has become accepted as a cost-effective approach to software development. In CBD, software development is considered to involve the composition of various software components. A software component is a self-contained unit of composition with contractually specified interfaces [2]. CBD is capable of reducing developmental costs and improving the reliability of an entire system [3]. In this paper, we use object-oriented (OO) programming language for the implementation of components. CBD does not always have to be object-oriented; however, it has been indicated that using OO paradigm/language is a natural way to model and implement components [4]. In fact, some of practical component architectures, such as JavaBeans [5] and Enterprise JavaBeans (EJB) [6], are based on OO technologies. As the functionality provided by a component gets larger, there is a tendency for the types of other components that can be used with it to become fixed. For example, when developing a e-mail processing program, the e-mail communications component, which would have quite a large funcManuscript received July 3, 2005. Manuscript revised October 13, 2005. † The author is with the National Institute of Informatics, Tokyo, 101–8430 Japan. †† The author is with the Ricoh Co., Ltd., Tokyo, 104–8222 Japan. ††† The author is with the Waseda University, Tokyo, 169–8555 Japan. a) E-mail:
[email protected] DOI: 10.1093/ietisy/e89–d.4.1421
tional scope, would tend to be used together with the text editing component. In this case, by embedding control code to use the later component inside the former component, the former component can use the later component directly. This embedding enables rapid application development, and allows the component to be used as envisioned by the original developer. Component connection refers the ability for one component to use the functionality of another independent component without creating any type of adapter at run-time. One such component connection framework is the Runtime Containment and Services Protocol [7] (hereafter, SP), which is built on the Java component architecture, JavaBeans [5]. JavaBeans allows software developers to construct Java applications by piecing components together either programmatically or visually. SP reduces the workload on developers using its components; however, with SP, the types of services a component can connect to at run-time are limited to classes anticipated by the component’s original developer, or subclasses of those classes. Even if the set of functions provided is the same, the class anticipated by a different developer may not be related to the actual provided service class or be a subclass of it. The safety of the connection is guaranteed by associating a static type to the service provided by the component; however, this results in low generality and flexibility, and raises the cost of reuse. Finally, with SP, dynamic changes of the components used in the target program are limited to cases when the service provider and requester components refer to the same class, or a subclass of it. In this paper, we define a type relation graph and propose a component model which uses connectivity on this graph to achieve component connection that is both safe and flexible. In our model we abandon an object-orientedlanguage class of a service for connection, and determine connectability based on a method type collection. In this way, our component model allows components to be connected at run-time even if required/provided method types are different in requester/provider components. We also show an example implementation of our model, and its usefulness. Experimental results show that our model is superior to conventional models in terms of the component-use cost and the capability of changing connections. The remainder of this paper is organized as follows. Next section introduces component connec tion and problems in conventional techniques. Section 3 describes our connection model and its implementation. In Sect. 4, we re-
c 2006 The Institute of Electronics, Information and Communication Engineers Copyright
IEICE TRANS. INF. & SYST., VOL.E89–D, NO.4 APRIL 2006
1422
port on our experiments and discuss the evaluation results. In the last section, we draw a conclusion and state future works. 2. Component Connection 2.1 Applicable Components The components treated in this paper are JavaBean components that are layerable according to the Bean Context [8]. We give a precise definition below. Definition 1 (Component) We call a class created in the Java language a component if it satisfies the following three conditions: • It possesses a default constructor which is callable externally. • It implements the java.io.Serializable interface. • It implements the java.beans.beancontext. BeanContextChild interface. The Bean Context is a multi-layered mechanism that provides a logical relationship structure (unrelated to the GUI structure) for JavaBean components. With the Bean Context, an object of a class (such as BeanContextServicesSupport) that implements java.beans.beancontext.BeanContext interface maintains state information about the surroundings in which a component is placed. A component can discover information about the context within which it resides at runtime by using BeanContext objects. The UML [9] class diagram in Fig. 1 shows the layer structure. Figure 1 also shows an example UML object diagram with context2 nested inside of context1.
2.2 Component Connection in CBD Process Component connection is the ability for one component to use the functionality of another independent component at run-time. The mechanism of achieving component connection can be used at the implementation activity of CBD process. CBD process is a model of the software development process which puts the reuse of components on the center of entire development process [10]. Figure 2 shows typical activities in CBD process and steps required in each activity. In Fig. 2, CBD process is composed of six activities: requirement gathering, analysis, design, implementation, testing, and component brokerage. The implementation activity is composed of three steps: the component implementation, component testing and component integration. Moreover, when conducting the implementation activity, application developers sometimes perform the component brokerage activity to register newly implemented components into a component repository, and to reuse existing components from the repository. In the implementation activity, when application developers reuse existing components and integrate these reused components into an application system, the mechanism of component connection including existing connection frameworks and our connection model/system (proposed in the next section) can be used to reduce integration costs since the mechanism automates such integration step. Moreover, the mechanism can let the existing components be reused as envisioned by each component’s original developer. 2.3 SP and Its Problem As one of component connection frameworks, SP is a mech-
Fig. 1
Structure of Bean Context.
Fig. 2
CBD process.
WASHIZAKI et al.: A FLEXIBLE CONNECTION MODEL FOR SOFTWARE COMPONENTS
1423
anism in which a component can be aware of its surroundings, and depending on the situation, automatically connect to other components. Components that provide services register them with a service provider. The service provider enables components that require the services within the same context to use them. For example, if a news reader component internally requires a mailer service, and the mailer is registered with the service provider, the news reader’s posting function can be enabled. But if the mailer is not registered with the service provider, the function can be deactivated. In this way, a component’s function can be enabled or disabled depending on the circumstances at run-time. With SP, functions that a component provides to other components are called services. The component providing the service is called the provider-side component, and the component requiring the service is called the requester-side component. In SP, there is also a service-provider program, which performs service management, and provides an interface for the services to be registered/un-registered and used. SP has a problem for reusability. To use a service, the requester-side component must be developed to use the service’s type, which is exactly the same as that of the actual provider component’s service. In CBD, components are not only used within organizations to which the components’ developers belong, but are also distributed and reused in other environments [11]. Therefore, third-party developed components might be difficult to be reused with SP. 2.4 Motivating Example As a motivating example, we consider the situation as shown in Fig. 3† . In Fig. 3, developer A creates the requesterside Graph component designed to use the provider-side 2DVector component through the VectorService service provided by 2DVector. Then developer B creates the VectorCalc component designed to provide the CalcService service, which has the same functionality as VectorService but with a different service class. Under these situations, we assume that developer C would like to create an application program using Graph with VectorCalc instead of 2DVector in order to improve ef-
Fig. 3
Situation of motivating example.
ficiency or for some other reason. To use the service in SP, the requester-side component must know the type of the target service being provided by the provider-side component. To change the service being used, if the service type being provided on the provider side is different, the application must be stopped, and the source code of the provider or requester-side component must be modified and recompiled. To do so requires knowledge of the programming language, and there is a modification cost for even the slightest interface difference. In the example in Fig. 3, Graph and VectorCalc cannot be connected as-is, so the part of Graph which uses the service will have to be modified. 3. Flexible Component Connections In order to resolve the problems discussed in the previous section, we introduce a new connection type that is different from the actual type required by the requester or provided by the provider component, and allows connectability to be determined based on a type relation graph. We then propose a new component connection model which offers more flexible connectability within the Bean Context without SP. 3.1 Proposed Connection Model In our connection model, we abandon the idea of assigning an object-oriented class to the service itself, and treat functions, which are provided by new connection types (called connection provision types), as the services. Connections are made based on evaluating the subtype or relaxed relation between requester’s connection request type and provider’s connection provision type. We call the connection request type and the connection provision type together the connection type. The connection request type is the collection of types of the methods that the requesting component would like to use. Thus, the connection request type is given as a list of the signatures of the required methods. The connection provision type is the collection of types of the methods provided by the provider component. The connection provision type can be obtained from a list of the signatures of the methods provided by the provider component. A method type is the collection of parameter value, return value and exception value types of a given method. Connection types with a subtype relation can be connected safely in terms of method type conversions. For example, we assumes that a component requests a calculation method which takes two parameters of type float (i.e., {float, float}), and another component provides a method which realizes the required function by taking two parameters of type double (i.e., {double, double}). In this case, the connection between these components can be † In this component diagram, required/provided interfaces of components represent service classes that are requested/provided by those components, and not Java language interfaces.
IEICE TRANS. INF. & SYST., VOL.E89–D, NO.4 APRIL 2006
1424
made safely because values of {float, float} can be considered as those of {double, double} based on the subtype relation between {float, float} and {double, double}. We call such a relation between the connection request type and the connection provision type the subtype relation. The subtype relation among connection types does not guarantee that the provided function, parameter value, return value, and exception value thrown by the provided method semantically match to the required ones; however, the subtype relation indicates the higher possibility (compared with other relations including the relaxed relation) of the semantic matching that might be judged and derived from such safe type/structural matching. In contrast, connection types with a relaxed relation cannot be connected safely as is, but some conversion of their input and output values allow them to be connectable. For example, if a component requests a method which takes two parameters of type double but the provided method which performs the required function has a parameter that is an array of double (i.e., double[]), the connection can be made by automatically converting {double, double} into double[]. We call such a relation among connection types the relaxed relation. As well as the subtype relation, the relaxed relation does not guarantee that the provided function, parameter value, return value, and exception value thrown by the provided method semantically match to the required ones; however, the relaxed relation indicates the possibility of the semantic matching that might be judged and derived from such connectivity with additional conversions. With this mechanism, when an application developer wants to change the provider-side component to a different one that satisfies the subtype or relaxed type relation with the former component, and the developer judges that these components semantically match regarding provided functions based on the subtype/relaxed relation, source code modification and compilation are no longer required. When changing the services provided, components with small type differences that could not connect with SP can now connect dynamically, without recompiling them. 3.2 Implementation of Connection Model Figure 4 shows an overview of the system that implements our connection model. In Fig. 4, the requesting component Graph uses a calculation service provided by the providing component VectorCalc in a graph display application program. ExtendedBeanContext is a class that implements BeanContext used in our system. GraphMain, the main class of the application, creates an object of ExtendedBeanContext as a context, and uses two components (Graph and VectorCalc). Graph and VectorCalc are registered with the context, and they are connected via ExtendedBeanContext that performs a value conversion function. Figure 5 shows how obtaining and performing the requested service is done in the source code of the requesterside component Graph. Line 1 defines the context in our
Fig. 4
Proposed system overview.
01: 02: 03: 04: 05: 06: 07: 08: 09: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22:
ExtendedBeanContext context = ... ; float a1, a2, result; Object[] argumentType1 = new Object[]{ Float.TYPE, Float.TYPE }; Object[] argumentType2 = new Object[]{ Float.TYPE }; Object returnType1 = Float.TYPE; Object returnType2 = Void.TYPE; Object exceptionType = Void.TYPE; MethodType methodType1= new MethodType( argumentType1, returnType1, exceptionType ); MethodType methodType2= new MethodType( argumentType2, returnType2, exceptionType ); Object[] argument1 = new Object[]{ new Float(a1), new Float(a2) }; Object[] argument2 = new Object[]{ new Float(a1) }; result = context.invoke( methodType1, argument1 ); context.invoke(methodType2, argument2); Fig. 5
Implementation of requester-side component.
component model. Lines 3∼15 define types for the requested method’s parameters, return values and exceptions. Lines 16∼17 and 18∼19 prepare the parameter values to be passed to the method when it is called. Finally, lines 20∼22 invoke two methods via the context, by passing the method types and parameter values in the context. In the following subsections, we will explain the precise definition of our connection model and the mechanism
WASHIZAKI et al.: A FLEXIBLE CONNECTION MODEL FOR SOFTWARE COMPONENTS
1425
of component connections based on the model in detail. 3.3 Type Relation Graph The types and type relation graph used in this paper are defined below. Definition 2 (Type) Our model uses primitive types, object types and set types as types. • Our model deals with all of primitive types, which are datatypes provided by Java language as distinct from composite (object) types: char, boolean, byte, short, int, long, float, and double. • Our model deals with all of Java’s classes and interfaces including the array of primitive/object types. Examples include java.lang.Integer class, java.io.Serializable interface, and int[] type. • Set types: A set type is a set of the same types. For example, a set of two double is a set type denoted as {double, double}. Definition 3 (Type relation graph) A directed graph, Γ = (V, E), satisfying the following five conditions is defined as a type relation graph. • V = VC ∪ VI ∪ VP ∪ VS VC is the set of class nodes corresponding to classes. Class nodes include nodes that correspond to array types such as the array of double (i.e., double[]). VI is the set of interface nodes corresponding to interfaces. VP is the set of primitive nodes corresponding to primitive types. VS is the set of set nodes corresponding to set types. All nodes are represented as rectangles that have corresponding type names inside when the type relation graph is illustrated in the form of a figure (shown in Fig. 6). • E = EE ∪ EI ∪ ES E consists of a set of subtype edges (EE), a set of initialization edges (EI), and a set of set edges (ES ). • EE ⊆ (VC ∪ VI) × VC ∪ VI × VI ∪ VP × VP EE is a set of subtype edges, which indicate that a class inherits another class/interface, an interface inherits another interface, or, a set of values that can be dealt with regarding a primitive type is the subset of values that can be dealt with regarding another primitive type. For example, (float, double) ∈ EE because the relation among value ranges of float and double is {x : float} ⊂ {y : double}. The subtype edge is denoted as −, such as float − double. • EI ⊆ (VC ∪ VI ∪ VP ∪ VS ) × VC EI is a set of initialization edges, which indicate that a value of a type v x can be converted to a value of a class vc by passing the value of v x as a parameter to the constructor of vc . For example, (float, java.lang.Float) ∈ EI because Float has a constructor Float(float f) that requires a value of float. The initialization edge is denoted as →, such as float→Float.
Fig. 6
Example of type relation graph.
• ES ⊆ VS × (VC ∪ VS ) ES is a set of set edges, which indicate that a set of type v x ’s values can be converted to a value of the array of the same type (i.e., v x []), or, to a set of v x ’s same super type’s values. In the latter case, the number of super types in the set must be the same as that of the original types. For example, ({ float, float }, float[]) ∈ ES , and ({ float, float }, { double, double }) ∈ ES . The set edge is denoted as · · · >, such as { float, float }· · · >float[]. Definition 4 (Reachability) On the type relation graph, node v is subtype-reachable from node u if there is a directed path from u to v and all edges on the path are subtype edges, or u = v, denoted as ∗ u − v. Similarly, node v is relaxed-reachable from node u if there is a directed path from u to v, or u = v, denoted as ∗ u v. Figure 6 shows an example of the type relation graph for several types in Java JDK standard library. In Fig. 6, we can see that Number and Object are subtypereachable from Float, and {double, double}, double[], float[], and Object are relaxed-reachable from {float, float}. 3.4 Connectability Settings The context maintains the requester-side and provider-side component information, as well as a connection permission setting. The connection permission expresses the strictness of component interconnections within the context. There are two types of connection permission settings: E sub (context) and Erel (context). For each context instance, the former is a boolean value that indicates whether the connection is allowed when a subtype relation is satisfied, and the later is that indicates whether the connection is allowed when a relaxed relation is satisfied. Connection permissions can be expressed in each context by setting each of these values to true or false. Connection permission settings are also applied to contexts included within a component’s own context, so if a context is included within an outer context, the context cannot have more lenient connection permission setting than that of the outer context. Also, when setting more strict connection permission of an outer context, it is necessary
IEICE TRANS. INF. & SYST., VOL.E89–D, NO.4 APRIL 2006
1426
laxed connections, our connection model makes the components become connectable and achieves flexible component connectivity. 3.5 Connectability Subtype/relaxed relations as well as subtype/relaxed connectability are defined below in terms of reachability on the type relation graph and the connection permissions settings. Definition 5 (Subtype/relaxed relation) e e For method types m : a → b − c, and m : a → b − c where c and c are exception types that would be thrown by these methods, we define a subtype relation ≤t and a relaxed relation t as follows: ∗
∗
∗
∗
∗
m ≤t m ≡ a − a ∧ b − b ∧ c − c ∗
m t m ≡ a a ∧ b b ∧ c c.
Fig. 7
Connection permission changes in the layered contexts.
to change the inside context permission as well, to avoid inconsistencies in the layered permission settings. To satisfy the restrictions above, the connection permissions are handled as follows (shown in Fig. 7). 1. Changing a connection permission setting is not allowed if an outer context is more strict than the new setting (an exception is thrown indicating this). 2. If a change is accepted, and if the connection permission setting has become more lenient than that of an enclosed context, the enclosed context must be notified of the change. Components can be used flexibly by allowing the connection permissions settings to be changed. For example, we assumes that the requester-side component Graph uses the provider-side component 2DVector. We also assumes that since these components can be connected based on a subtype relation, the connection permission setting would permit subtype relation connections. Then, to improve running efficiency, you may want to change the provider component to VectorCalc, but the types of the services provided by 2DVector and VectorCalc are slightly different. In this case, conventional models/systems would not allow a connection; however, by changing the setting to permit re-
m satisfies a subtype relation to m if the method type of parameter a is subtype reachable from a, the method type of the return value b is subtype reachable from b , and the method type of exception c is subtype reachable from c . Since parameters of the method type in an object-oriented type system follow a contravariance rule in terms of subtyp∗ ing [12], a − a must be satisfied if m ≤t m. In contrast, since return values and exceptions of the method type follow ∗ ∗ a covariance rule in terms of subtyping, b − b and c − c must be satisfied if m ≤t m. Similarly, m satisfies a relaxed relation to m if the method type of parameter a is relaxed reachable from a, the method type of the return value b is relaxed reachable from b , and the method type of exception c is relaxed reachable from c . Definition 6 (Subtype/relaxed connectability) For the connection request type C1req = {m1 , . . . , mi } published by the requester-side component C1, and the connection provision type C2 pro = {m 1 , . . . , m i , . . . , m n } published by the provider-side component C2 registered within the same context instance context, the subtype connectability match sub and relaxed connectability matchrel are defined as follows: match sub (C1req , C2 pro ) ≡ m 1 ≤t m1 ∧ . . . ∧ m i ≤t mi ∧(E sub (context) ∨ Erel (context)). matchrel (C1req , C2 pro ) ≡ m 1 t m1 ∧ . . . ∧ m i t mi ∧ Erel (context). A pair of components has relaxed connectability if the provider-side component has methods which satisfy a relaxed-relation with all of the method types requested by the requester-side component, and if the connectivity permission setting within the context is set to allow the relaxedrelation connection.
WASHIZAKI et al.: A FLEXIBLE CONNECTION MODEL FOR SOFTWARE COMPONENTS
1427
(a). Find the shortest path p = {e1 , . . . en } from the m’s parameter types to the m ’s parameter types on the type relation graph, where e is a subtype or initialization or set edge. (b). Perform the following for all edges from e1 to en :
3.6 Connection Procedure Flexible connectability is achieved by searching among the registered provider components for a connectable component, and if found, automatically converting values of method parameters, return values and exceptions to those of connectable types as required. The user of our connection system does not need to be aware of these value conversions. Once connectability has been determined, if connectable, the method is called after automatically converting the values supplied by the requester side to values of types required by the provider-side. Then, after the call, the value of the return value is converted to that of the type expected by the requester side. If an exception was thrown on the provider side, its value is converted to an exception of a type expected by the requester side. Moreover, as with SP, our system can handle a layered structure where one context can be nested within another context. The procedure for determining which providercomponent to connect to, and how to convert values is as follows: 1. Construct a type relation graph using all arising types. 2. Create a context defined by our system. 3. Create a requester-side component instance and register it with the context. 4. Register the provider component with the context. 5. Set the connection permission setting for the context. 6. The requester-side component retrieves the context to which it belongs. 7. In the context, find all existing and connectable provider-side components. 8. If this search results in a single usable provider-side component, this becomes the connection component. If multiple components are found, the following procedure is used to select one: • Components with a subtype relation are given precedence. Relaxed-relation components are used only if there are not subtype-relation components. • If there are multiple components with the same connection relation, the sum of the path lengths on the type relation graph for each method is calculated, and the component with the shortest total length is selected. 9. When the method is requested to be called, if the method type of the requested method is m, and the collection of method types provided by the provider side is {m 1 , . . . , m n }, then method m which satisfies m ≤t m when E sub (context) = true or method m which satisfies m t m when Erel (context) = true is processed as follows: • For the connection permission E sub (context), pass parameter values without conversion. For the connection permission Erel (context), pass parameter values with the following conversion:
– If the selected edge e = (ta , tb ) is a subtype edge, pass the parameter values to the method without value conversion. – If e is an initialization edge, pass the values to the tb ’s constructor which takes ta as parameter types to create an instance of tb , and pass the created instance to the method. – If e is a set edge and tb is a set type, pass the parameter values to the method without value conversion. – If e is a set edge and tb is an array type, convert the values to an array, and pass the converted value to the method. • If a value is returned as a result of executing the method: for the connection permission E sub (context), return the result without conversion to the requester-side method. For the connection permission Erel (context), find the shortest path from the m ’s return value type to the m’s return type on the type relation graph, convert the return value as (b) in the case of parameter values, and return the converted value. • If an exception occurs while executing the method, convert the exception value as in the case of return value and return it to the requester-side method. 3.7 Example As an example of the above-mentioned process, we consider the situation explained in Sect. 2.3. We assume that the connection request type Graphreq of Graph is: Graphreq ≡ {method1 : {float,float} → double, method2 : float → void}. We assumes that 2DVector and VectorCalc implemented as shown in Fig. 8 provide the printVec() and
public class 2DVector implements BeanContextChild, Serializable { public float calcVecSize(double a, double b) { ... } public void printVec(float b) { ... } } public class VectorCalc implements BeanContextChild, Serializable { public float vecSize(float[] a) { ... } public void printOut(Double b) { ... } } Fig. 8
Implementation of 2DVector and VectorCalc.
IEICE TRANS. INF. & SYST., VOL.E89–D, NO.4 APRIL 2006
1428
printOut() methods respectively to output vectors on the console, and the calcVecSize() and vecSize() methods respectively to calculate the inner-product of a vector. In this case, connection provision types 2DVector pro and VectorCalc pro of 2DVector and VectorCalc are defined as follows: 2DVector pro ≡ { calcVecS ize : {double,double} → float, printVec : float → void}. VectorCalc pro ≡ {vecS ize : float[] → float, printOut : Double → void}. We consider a situation where both Graph and VectorCalc are registered in the same context. For Graphreq on the requester-side, 2DVector pro on the provider-side satisfies a subtype relation, but VectorCalc pro does not. However, VectorCalc pro does satisfy a relaxed relation with Graphreq . For example, for the parameters ∗ of the vector output method, float Double is satisfied since the java.lang.Double class has a constructor ∗ with a double parameter and float − double. Thus, if the developer allows relaxed relations in the connection permission settings, (Erel (context) ≡ true), Graph and VectorCalc can be connected as follows: matchrel (Graphreq , VectorCalc pro ) ≡ (float[] → float t {float,float} → double) ∧ (Double → void t float → void) ∧ Erel (context) ≡ true. As an example of value conversion in the abovementioned connection, the conversion of the value of the required method’s parameter type float to that of the object type Double provided by the method VectorCalc.printOut() is processed as follows: (a). The shortest path from float to Double on the type relation graph is found as p = {(float, double), (double, Double)}. (b). The value is converted as follows: – A value of float is considered as a value of double as-is. – The value of double is then passed to the Double’s constructor Double(double d), to create an instance of Double. 4. Experimental Evaluation To evaluate the usefulness of our system, we measured the modification cost and run-time efficiency in comparison with conventional SP. Moreover, we evaluated the possible connection coverage achieved by our system. 4.1 Modification Cost When Changing the Provider Component We compared the difference in component usage cost under
Table 1
Modification cost for using new provider-component.
Connection model Conventional (SP) Our model
Component’s modification cost Requester-side Provider-side 8 0 0 0
SP and under our component model when using a component developed by a third party. As a sample program, an SP compliant service WordCount [8] which counts the number of words in a text file, was modified to be provided by an independent provider-side component WordBean. In this sample, the requester-side component for the WordCount service is DocumentBean [8]. Regarding the requester-side component code, we measured the modification cost requested when changing the provider-side component. We prepared a new providerside component WordBean2 [13] with the same functionality as WordBean, but has different method types to provide the service. First we developed applications which connect DocumentBean and WordBean using each of SP and our system. Then, we adapted each of these applications to use WordBean2 instead of WordBean. The numbers of modified code lines in components using SP and our system are shown in Table 1. In Table 1, the application using our system required no modification for both provider-side and requester-side components. Therefore, developer can easily change provider-side components even at run-time. In contrast, the application using SP required modifications of several code lines in the requesterside component. Because no modification was required, the componentuse cost was much lower with our system when performing service provider changes than that with SP. Moreover, our system has a significant benefit of realizing dynamic service provider changes. 4.2 Run-Time Efficiency Because it affects the startup time in our system, we measured the time required to build the type relation graph for all Java standard library classes. The environments used for this experiment were Java 2 SDK Standard Edition 1.3.1 06 as library, Intel Pentium 4 2.6C as CPU and Windows 2000 as OS. The average time over ten measurements was 10.71 seconds. Since construction of the type relation graph is only required when the system is first initialized, this time is not considered a significant problem. Next, to evaluate whether connections with our system can be achieved within realistic time periods, we compared the execution time using SP and our system. In this comparison, we used WordBean as the provider-side component and DocumentBean as the requester-side component. While changing the number of connection times, we measured the execution time in two situations: the situation where the provider-side component has a light weight task (counting 10 words), and the situation where that has a heavy weight task (counting 100,000 words). The results are shown in
WASHIZAKI et al.: A FLEXIBLE CONNECTION MODEL FOR SOFTWARE COMPONENTS
1429 Table 2
Domain groups and the number of subtype/relaxed relations. Domain SMTP Client POP3 Client Progress Bar Clock Calculator (Total)
Fig. 9
Fig. 10
NC 3 3 3 3 2 14
NS 6 6 6 6 2 26
R 0 0 0 0 0 0
P sub 0 0 2 1 0 3
Prel 0 0 2 1 0 3
Execution time when counting 10 words.
Execution time when counting 100,000 words.
Fig. 9 and Fig. 10 respectively. For ten words, since the actual content processed is extremely small, our system, which takes more execution time to make the connection, required about 2.5 times the execution time compared to SP. Because the content processed is large for the 100,000 words case compared to the ten words case, the time required for making the connection in our system is relatively short, so the difference is smaller at about a 30% increase. We do not consider this difference to be a significant problem in most cases, when the actual service provided by the provider component requires a certain amount of execution time. The averages of the execution time per one method execution in our system were 0.014 and 0.102 [sec] for ten words and 100,000 words respectively, while those in SP were 0.005 and 0.073. Since each method execution in our system had been performed in short terms, we think our system is useful in any cases except for the cases where the high-performance calculations are required. 4.3 Connection Coverage We evaluate the possible connection coverage achieved by our system in several different application domains by using existing actual JavaBeans components. We used 14 components provided by different developers at [14]–[20] as evaluation samples. From among all of the samples, we set five domain groups in which all components functionally resemble each other based on documents attached to components. Table 2 shows the number of components for each domain group (denoted as NC ). We expected that when all or some of methods provided by a component Cx (as the provider-side component) in each group has been used in our system, application developers can easily change Cx to other components (Cy) in
the same group without any modification for a requesterside or provider-side component. Such expectation can be confirmed by checking that match sub (Cx pro , Cy pro ) or matchrel (Cx pro , Cy pro ) would be satisfied. In Table 2, the number of all possible componentreplacement combinations for each group is denoted as NS . The value of NS is always NC × (NC − 1). For example, if there are two components (C1 and C2) in the same group, NS = 2 because all possible replacement combinations are the replacement from C1 to C2 and that from C2 to C1. We checked the subtype or relaxed relation would be satisfied among components in the same group, under a situation where all methods of the provider-side component before replacement have been used. The row of R in Table 2 shows the obtained results as the numbers of replacement combinations that satisfy the subtype/relaxed relation. The results show that our system does not achieve any component re-connection after replacing provider-side components under such situation. However, we think all of methods provided by components are not always used in any situation; components might provide optional (not always used) methods together with primary methods. Therefore, we checked the subtype/relaxed relation would be satisfied, under a situation where only primary methods of each provider-side component have been used before and after replacement. For example, regarding components in the Progress Bar group, we assumed that components’ methods for representing texts with progress bars are not used; we assumed only methods for representing progress bars are used. The row of P sub /Prel in Table 2 shows the obtained results as the numbers of replacement combinations that satisfy the subtype/relaxed relation under such situation. The results show that our system achieves component re-connection in three cases, and the connection coverage achieved by our system is 11.5%. For example, in the Progress Bar group, a requesterside component that requires primary functions provided by the component ProgressBar [17] can be safely connected to other components ob.progress.Progress [20] and kobu.Meter [19]. This result originates in that these three components in the Progress Bar group have methods that provide a common function concerning the representation of progress bars, and those methods are similar with respect to the types of parameters and return values. For example, Table 3 shows the progress position setting/getting methods which are found to be in common. These methods are similar in terms of types, and satisfy subtype relations. The obtained coverage is not high; however, we con-
IEICE TRANS. INF. & SYST., VOL.E89–D, NO.4 APRIL 2006
1430 Table 3
Comparison of progress position setting/getting methods.
Component ProgressBar Progress Meter
Setting method void setPersent(int) void setPosition(int) void setCurrent(int)
Getting method int getPersent() int getPosition() int getCurrent()
firmed that our system achieves automatic component connection based on subtype relations between the provider and requester-side component in several cases. In such cases, our system brings great reduction in the component-use cost compared with the conventional technique (measured in Sect. 4.1). 5. Related Work Our model is the first one to flexibly connect components at run-time by automatically converting values based on a type relation graph. Nonetheless, our model bares resemblance to several existing techniques [21]–[23]. Zaremski and Wing have proposed a flexible method matching technique for retrieving candidate components that match a given user request [21]. In [21], to determine component compatibility, a component type from the method collection is applied, and lenient component compatibility is determined using that type. This technique is similar to our method regarding the way of determining compatibility; however, with our model, in addition to finding a usable component, we achieve a dynamic component connection by converting input and output values appropriately at run-time. Architecture Specification Language (ASL) [22] is a mechanism which uses subtype relations to determine intercomponent connection relationships. In ASL, determining connectability is limited to logical subtype relations (subtype relations including pre/post conditions for methods). Moreover, ASL cannot implement the flexible connectability provided by the per-context connection permission settings in our model. Oreizy et al. have proposed an architecture-based approach to runtime software evolution based on a model, called “C2”, which consists of components, connectors and messages [23]. In C2, since components communicate by passing asynchronous messages through connectors, component connections can be dynamically changed with a support of an interactive development tool. However, C2 cannot support the automatic connections between components that require/provide different messages. Lorenz and Petkovic have proposed a development tool which extends BeanBox [24], and handles the layered structure of Bean Context components visually [25]. We are planning to extend this tool to provide a visual application development environment which supports our system. 6. Conclusion and Future Work We have proposed a component model providing flexible component connectivity, and is built upon JavaBeans and
Bean Context. We have introduced the subtype connectivity and relaxed connectivity to realize the flexible connection based on reachability on a type relation graph. We have also built an implementation of this model. In our model we abandon an object-oriented-language class of a service for connection, and determine connectability based on a method type collection. In this way, our component model allows components to be connected at run-time even if required/provided method types are different in requesterside/provider-side components, where using those components has required source code modification in a conventional model. As a result of experimental evaluations, we confirmed that our system is effectively applicable where (a) primary functions are required by the requester-side components, (b) the provider-side components have methods that provide such expected functions, and (c) the provided methods are similar to those required by the requester-side with respect to the types of parameters and return values. In such case, our system brings great reduction in the component-use cost compared with the conventional technique. Our system is currently developed to accept JavaBeans that are layerable according to the Bean Context. However, our model can be similarly applied to other component architectures that use OO languages for components’ implementation. In further research, we will extend our system to accept components based on other component architectures, such as ActiveX [26]. Moreover, we will conduct largescale experiments for evaluating usability of our model under complex applications that require a number of component connections. References [1] G.T. Heineman and W.T. Councill, Component-Based Software Engineering: Putting the Pieces Together, Addison Wesley Professional, 2001. [2] C. Szyperski, Component Software: Beyond Object-Oriented Programming, Addison-Wesley, 1999. [3] H. Washizaki, H. Yamamoto, and Y. Fukazawa, “A metrics suite for measuring reusability of software components,” Proc. 9th IEEE International Symposium on Software Metrics, pp.211–223, 2003. [4] J. Hopkins, “Component primer,” Commun. ACM, vol.43, no.10, pp.27–30, 2000. [5] G. Hamilton, JavaBeans 1.01 Specification, Sun Mircosystems, 1997. [6] L.G. DeMichiel, Enterprise JavaBeans 2.1 Specification, Sun Microsystems, 2003. [7] L. Cable, Extensible Runtime Containment and Services Protocol for JavaBeans Version 1.0, Sun Microsystems, 1999. [8] S. Hommel, Trail: JavaBeans: Lesson: Using the BeanContext API, Sun Microsystems, 1999. http://java.sun.com/docs/books/tutorial/javabeans/ [9] Object Management Group, OMG Unified Modeling Language Guide Specification Version 1.4, 1999, http://www.uml.org/ [10] J.Q. Ning, “A component-based software developement model,” Proc. 20th Annual International Computer Software and Applications Conference, pp.389–394, 1996. [11] M. Aoyama and T. Yamashita, “Software commerce broker over the Internet,” Proc. 22nd IEEE Annual International Computer Software and Applications Conference, pp.430–435, 1998.
WASHIZAKI et al.: A FLEXIBLE CONNECTION MODEL FOR SOFTWARE COMPONENTS
1431
[12] L. Cardelli, “Type systems” in Handbook of Computer Science and Engineering, CRC Press, 1997. [13] Fukazawa laboratory, Waseda University, FukaBeans, http://www.fuka.info.waseda.ac.jp/Project/CBSE/fukabeans/ [14] M. Watson, Creating JavaBeans: Components for Distributed Applications, Morgan Kaufman, 1997. [15] J. Neil, JavaBeans Programming from the Ground Up, McGrawHill, 1998. [16] E. Harold, JavaBeans: Developing Component Software in Java, IDG Books, 1998. [17] Jupitermedia Corporation, JARS.COM: The #1 Java Review Service, http://www.jars.com/ [18] IBM Corporation, alphaBeans: JavaBeans(tm) by IBM, http://www.alphaworks.ibm.com/alphabeans/ [19] DigitalCats, http://www.javacats.com/ [20] Singapore Java Users Group, http://www.sjug.org/showcase/ [21] A.M. Zaremski and J.M. Wing, “Signature matching: a tool for using software libraries,” ACM Trans. Softw. Eng. Method., vol.4, no.2, pp.146–170, 1995. [22] F. Bronsard, D. Bryan, W. Kozaczynski, E. Liongosari, J. Ning, A. Olafsson, and J. Wetterstrand, “Toward software plug-and-play,” Proc. International Symposium on Software Reusability, pp.19–29, 1997. [23] P. Oreizy, N. Medvidovic, and R.N. Taylor, “Architecture-based runtime software evolution,” Proc. 20th International Conference on Software Engineering, pp.177–186, 1998. [24] Sun Microsystems, BeanBox, http://java.sun.com/products/javabeans/ [25] D. Lorenz and P. Petkovic, “Design-time assembly of runtime containment components,” Proc. 34th International Conference on Technology of Object-Oriented Languages and Systems, pp.195– 204, 2000. [26] A. Denning, ActiveX Controls Inside Out, Microsoft Press, 1997.
Hironori Washizaki is an assistant professor at National Institute of Informatics, Tokyo, Japan since 2004 and at The Graduate University for Advanced Studies since 2005. He obtained his Ph.D. in Information and Computer Science from Waseda University, Japan in 2003. He was a Research Associate at Waseda University from 2002 to 2004. His research interests include object-oriented programming, component-based development, software testing, software metrics, and software patterns.
Daiki Hoshi is a researcher at Ricoh Co., Ltd., Tokyo, Japan. He obtained his Master’s degree in Information and Computer Science from Waseda University, Japan. His research interests include component-based software development and embedded system development.
Yoshiaki Fukazawa is a professor at Waseda University, Tokyo, Japan. He obtained his Ph.D. in Engineering from Waseda University, Japan. His research interests include object-oriented programming, agent-oriented software, software engineering, and computer architecture.
