Trading for COTS components in Open Environments Luis Iribarne University of Almer´ıa Escuela Polit´ecnica. 04120 Almer´ıa, Spain
[email protected]
Abstract Trading is a well-known mechanism for searching and locating services in object-oriented systems. However, current traders present some limitations when tried to be used in open component-based environments. In this paper we analyze the required features that COTS components traders should have, and describe the design and implementation of COTStrader, an Internet-based trader for COTS components that handles the heterogeneity, scalability and evolution of COTS markets.
1. Introduction In the last decade, Component-Based Software Engineering is generating tremendous interest due to the development of plug-and-play reusable software, which has led to the concept of ‘commercial off-the-shelf ’ (COTS) components. Although currently more a goal to pursue a than a reality, this approach moves organizations from application development to application assembly. Constructing an application now involves the use of prefabricated pieces, perhaps developed at different times, by different people, and possibly with different uses in mind. The ultimate goal, once again, is to be able to reduce development times, costs, and efforts, while improving the flexibility, reliability, and reusability of the final application due to the (re)use of software components already tested and validated. This approach is challenging some of the current SE methods and tools. For instance, the traditional top-down development method based on successive refinements of the system requirements until a suitable concrete implementation of the final application’s components is reached is no longer valid as such. In CBSE the system designer also has to have into account the specification of pre-developed COTS components that live in software repositories, which must be even considered when building the initial system’s requirements in order to incorporate them into all phases of the development process [18, 25]. There is significant
Jos´e M. Troya and Antonio Vallecillo University of M´alaga ETSI Inform´atica. 29071 M´alaga, Spain {troya,av}@lcc.uma.es shift from a development-centric towards a procurementcentric approach [29], aimed at the search and acquisition of COTS components for building software applications. Here, system architects, designers, and builders must accept the trade-offs among three main concerns: user requirements, system architecture, and COTS products [12, 20]. Under this new setting, the proper search and selection processes of COTS components have become the cornerstone of any effective COTS development. However, those processes currently face serious limitations, generally due to two main reasons. First, the information available about the components is not expressive enough for their effective selection. And second, the search and evaluation criteria are usually too simple to provide practical utility. In the first case, the black-box nature of COTS components difficulties the understanding of their internal behavior; besides, only functional properties of components are usually taken into account, whilst other information crucial to component selection is missing, such as protocol or semantic information [30], or non-functional requirements [1, 9]. On the other hand, component searching and matching processes are delegated to traders; but the problem is that current traders do not provide all the functionality required for an effective COTS component trading in open and independently extensible systems (e.g., Internet), as discussed in [31]. In this paper we focus on the requirements for an effective trading of COTS components in open environments, analyze some of the limitations of current traders, and present a trading service that fulfills many of the previously identified requirements. An extension to the information used for describing COTS component services is also discussed, where not only functional aspects of the components are taken into account, but also quality aspects and non functional requirements (NFRs), architecture constraints, and other non technical factors. Based on this information, a template for describing service queries is defined. With all this, it is possible to improve both the service ‘export’ and ‘import’ processes, and design and develop enhanced traders that make use of the Internet facilities for locating and retrieving COTS components.
2. Requirements for a COTS trader
read and write to the same service offer repository; traders are not directly aware of each other, so this approach is easily scalable. The problem is the implementation of a globally accessible repository. However, this is not an issue in the Internet architecture, since search engines naturally provide such a repository.
Trading is a well-known concept for searching and locating services. In a trader-based architecture, a client component that requires a particular service can query a matchmaking agent (called the trader) for references to available components that provide the kind of service required. Service advertisements are usually called exports, while queries are called imports. The trader provides just the references to possible service providers, but without intervening in the service provision itself, which is a private matter between the client and the server (the one selected by the client from the list of candidates returned by the trader). Trading is not only relevant to CBSE; context-aware software, such as mobile computing or adaptable applications, can greatly benefit from trading since it provides service discovery in local environments and enables automatic application re-contexting. Furthermore, enhanced traders with QoS facilities can provide the means for self-configuring multimedia applications. In this paper we will concentrate only on COTS component trading; however, most of our discourse is also applicable to all disciplines in which trading is required. With regard to components, we will adopt Szyperski’s definition, and consider that components are binary units of possibly independent production, acquisition and deployment that interact to form a functioning system [27]. The adjective COTS will refer to a special kind of (usually large grained) components, which are specially designed, developed and marketed to be used in CBSE environments.
3. A trader is more than a search engine. Traders may superficially resemble search engines, but perform more structured searches. In a trader, the matchmaking heuristics need model the vocabulary, distance functions and equivalence classes in a domainspecific property space, in contrast to (rather, in addition to) the keyword-based, domain-neutral matchmaking supported by document search engines. 4. Service composition. Current traders focus on oneto-one matches between client requests and available service instances. A compositional trader should also consider one-to-many matches, in which a client request can also be fulfilled by appropriately composing several available services, that together provide the required service. 5. Service adaptation. One-to-one exact matchmaking is also inadequate in a number of situations, as there may be format, QoS, or performance mismatches between the client request and the closest matching service instance. This problem can be addressed by the trader by composing such a service instance with format translators and performance monitors to reduce mismatches.
2.1. Wish-list
6. Multiples interfaces. In object-oriented systems, services are described by interfaces, where each object provides just one interface (although it may be obtained from many by using multiple inheritance). However, components simultaneously offer several interfaces, and thus services should be defined in terms of sets of interfaces. This fact has to be specially considered when integrating components, since conflicts may appear between components offering common interfaces [14].
The following is a list of features and characteristics that traders should have in order to provide an effective COTS component trading service in open systems. 1. Heterogeneous component model. A trader should not restrict itself to a particular component or object model, but to be able to (simultaneously) deal with different component models and platforms, such as CORBA, CCM, EJB, COM, .NET, etc. Heterogeneous traders should trade with multiple service access protocols, and should be able to accommodate to the evolution of the current models, and to new ones as soon as they appear.
7. Softmatchmaking. Traditional ‘exact’ matches between imports and exports are very restrictive in real situations, in which more ‘relaxed’ matching criteria should be used. This is even more important when trading for services in open and independently extensible systems, such as Internet, where service and method names are chosen in a non-standardized way. Therefore, partial matches should be allowed when building the list of candidate components in many situations.
2. Federation. Cooperating traders can federate using different strategies. The direct federation approach requires traders to directly communicate to (and know of) the traders they federate with. This is a very secure and controlled scheme, but the communication overhead grows with the number of federated traders. In the repository-based federation multiples traders 2
2.2. Shortcomings of current traders
8. Signature information is not enough. Component behavior, NFRs, QoS, marketing information, and semantic data should be also considered for an effective trading.
Existing traders mostly follow the ODP model [15], and therefore they present some limitations when their features are compared against the previous list of requirements. Actually, based on the experience obtained from the existing industrial implementations of the trading service [22, 11, 24, 26] and on the basis of some closely related works [4, 5, 17, 31], we can see how current traders: use homogeneous object models only; use direct federation; do not allow service composition or adaptation; work with ‘exact’ matches at the signature level only; do not allow multiple interfaces; and they are based on a push model only. Our main goal is to design a trader that can help overcoming these limitations, specifically designed to deal with COTS components in Internet-based environments.
9. Extended subtyping procedures. Current traders organize services in a service type hierarchy in order to carry out the service matching process. Central to type matching is the notion of type subtyping (or type conformance). TypeA is a subtype of TypeB (TypeA 6 TypeB) if instances of TypeA can substitute instances of TypeB and clients will not be able to detect the change. Subtyping is now checked merely at the signature level, but extensions need to be defined in order to cope with ‘semantic’ information — in the style of [2, 10, 16, 33]—, ‘protocol’ information [7, 21], QoS, etc.
3. Services and Service Types
10. Use of heuristics and metrics (preferences). Users should be able to specify heuristic functions and metrics when looking for components, specially in the case of ‘soft’ matchmaking.
Components offer services, clients request services, and traders deal with services. Therefore, we should start by defining what a service is. We will adopt here the ISO definition of service given in the ODP trading service specification [15]: “A service is a set of capabilities provided by an object at a computational level. A service is an instance of service type”. In ODP, a service type is an interface signature type, a set of property definitions, and a set of rules about the modes of the service properties. Interface signatures describe the service functionality, in terms of attributes and methods (ODP is object-oriented). Service properties are triplets (name, value type, mode), where the name identifies the property (e.g., AllowEncryption), the value type establishes the type of allowed values for the property (e.g., boolean) , and the modes specify whether the property is read-only or readand-write, or whether it is optional or mandatory. In addition, properties can also be declared as dynamic, which means that instead of having assigned a fixed value, they have an external evaluator associated, which is in charge of dynamically providing the current value of the property (e.g., the current length of a queue). This kind of ODP service types are the ones commonly used in most current traders. However, we need extend this definition in order to address some of the limitations pointed out above. In our context, a service type will consist of four main parts. The first one describes the functional (i.e., computational) aspects of the service, including both syntactic (i.e., signature) and semantic information. Unlike the ODP service type, that contains just one interface, our functional definition of a service will host the set of interfaces offered by the service, and the set of required interfaces that any instance of the service may require from other components
11. Independently extensible. The information managed by the trader should be able to be extended by users in an independent way, and still the trader be able to use all its functionality and capabilities. 12. Scalable. No matter how traders federate or organize, scalability should be guaranteed in large open distributed environments such as the Internet. 13. Both ‘automatic’ and ‘store and forward’. If a trader cannot fully satisfy a request, either it automatically replies back to the client with a denial (automatic behavior), or it may also store the request and postpone the reply until a suitable service provider is found (store and forward). 14. Support of both ‘push’ and ‘pull’ models. In a push model, exporters directly contact the trader to register their services with it. A probably more convenient way of working in a large open and distributed environment is by using a pull model, in which exporters make available the publicity of their provided services at their Web sites, for instance, and traders are continuously looking for new services. Bots and search engines can be used to enhance current traders, which use a push model, crawling the Web looking for services and ‘pushing’ them into the traders. 15. Delegation. Traders should be able to delegate requests if they cannot resolve them to other (smarter) traders. Delegation of the complete request or just parts of it should be desirable.
3
when implementing its supported interfaces. Semantic information can be described with pre/post conditions, as well as by means of service access protocols, which specify the relative order in which a component expects their methods to be called, and the way it calls other components’ methods. The second part describes the non-functional aspects of the service, e.g., QoS, NFRs, etc. We will express them in a similar way to ODP, by means of service properties. The third part contains the packaging information about how to download, deploy and install the COTS component that provides the required service, including implementation details, context and architectural constraints, etc. Finally, the marketing information deals with the rest of the non-technical issues of the service, such as licencing and pricing information, vendor details, special offers, etc.
scheme, the one describing the OnePlaceBuffer component.
4. A COTS trader for Open Systems
4.1.1
... ... ... ...
As we can see in the XML document, the description of a component begins with a tag where the DTD namespaces used and the name of the component are established. Then, the body of the XML document describes the four main parts a service type consists of, as previously defined in section 3. Functional description
The first section describes all the computational aspects of the component, in terms of the sets of its provided and required interfaces. This section has three main parts called providedInterfaces, requiredInterfaces, and serviceAccessProtocols:
Once we have identified the requirements for a COTS components trader in open systems, and defined what services should look like for effective service advertisement, matching, and deployment, this section describes an implementation of an Internet-based trader for COTS components, called COTStrader. We have divided this section into three main parts. The first one deals with component and services documentation, i.e., how to describe the services provided by the COTS components in terms of their service types. The second part defines how clients express service imports. Finally, section 4.3 describes the trading process of COTStrader. We have used XML as the language for documenting components (i.e., describing services) and for expressing queries. XML is simple, extensible, and widely accepted within the Internet community. In order to illustrate our proposal we will use a simple example. It is a one-place buffer component, with usual operations read() and write(). It also makes use of another component for printing out the values written in its cell, using method print() every time a new value is written. Despite its simplicity, this example will allow us to show our approach to documenting components, the export and import processes, and the way the trader works, all within the restricted space of this paper. This example and some others are available at the COTStrader Web site http://www.cotstrader.com/.
... ... ... ... ...
The first two parts describe the component interfaces, and the third one deals with the service access protocols that define the relative order in which the component expect its methods to be called, and the order it call other components’ methods. In our example, the first section is described as follows.
4.1. Exporting services (documenting components) For the description of a COTS component we have designed some DTD templates based on the W3C’s XML schema language. The following shows a simple instance of the
4
interface OnePlaceBuffer { void write(in int x); int read(); }; ...Larch specification of the interface here ...
As we can see, not only the syntactical description of the interfaces (i.e., their signatures) can be expressed, but also their behavior using any given notation, such as Larch in this example (omitted for space reasons). We did not want to commit to any particular notation for expressing the information contained in the XML templates. Therefore, the “notation” attribute is present in most fields. It currently has several pre-defined values, but it is a matter of clients and servers to agree in the values they want to use. More than providing a syntax for importing and exporting services, our goal was to provide a template that could be used for clients and service providers to express the information they want to share, no matter which it was, and that could evolve as the market did. Behavioral information can also be described in a separate file using the href attribute, or even ommited because this information is otional. Only signature information is mandatory.
Full(ref,out,x) = ref?read(rep) . rep!(x) . OnePlaceBuffer(ref,out) ;
In this example the actual description is given in-line, and again, there are two external references to the programs that implement the exact and soft matchmaking checks [6]. 4.1.2 Non-functional description In our approach we have adopted the ODP way of describing non-fuctional properties, using properties as described in section 3. ODP’s properties are the usual way in which the non-functional aspects of objects, services and components are expressed in the literature. We suggest using W3C types for describing properties, although any notation is valid for describing them (e.g., the OMG’s CORBA Component Model (CCM) style [23, page 10-365], that also uses an XML vocabulary). Thus, inside the tag there will be a collection of properties, each one indicated by a tag, and with a type and a value associated.
interface out { oneway void print(in int x); };
xsd:string SAFE xsd:int 1 xsd:boolean xsd:string storage,bounded
The main information described in this XML template usually comes inside the tag. This information can be either implicitly included in this tag, or a reference to an external location can be made using the href attribute. Associated to each notation for describing behavior, there may also be a reference to a couple of procedures that will allow the trader to do the matchmaking process. In this example, “exactMatching.cgi” is the name of a program that is able to decide whether two behavioral descriptions A and B , written in Larch, satisfy that A can replace B [10]. Analogously, the second program “softMatching.cgi” is the one in charge of implementing the softmatchmaking process, however it may be defined in this case. Apart from the two sections that describe the provided and required interfaces, a third (optional) part deals with the semantic aspects of the component that globally describe its behavior, and that cannot be captured by the individual interfaces, namely, the relative order in which the component expects their methods to be called, and the way it calls other components’ methods. This is commonly known as protocol information [6, 30], and can be expressed in many different notations, such as Petri Nets, π-calculus, Message Sequence Charts, and so on.
Please notice how we allow keyword-based searches too, including the special property “keywords”. Dynamic properties can also be implemented in this approach, by declaring the reference to the external program that will evaluate their current value. Properties can also be described in a separate file, which can be pointed at from the tag as usual:
4.1.3
Packaging/architectural constraints
This part deals with the packaging and deployment information of the component providing the service. Again, there is a tag with the appropriate information, which is written according to a particular notation, and either implicitly encoded in the XML document, or an href reference to it must be given.
OnePlaceBuffer(ref,out) = ref?write(x,rep) . out!print(x) rep!() . Full(ref,out,x) ;
5
In this example, the CCM’s “softpackage” [23] description style is used. A CORBA component package maintains one or more implementations of a component, and consists of one or more descriptors and a set of files. The descriptors describe the characteristics of the package —such as its contents or its dependencies— and points to its various files. This information allows to describe resources, configuration files, the location of different implementations of the component for different operating systems, the way those implementations are packaged, the resources and external programs they need, etc. For a detailed description of this information, we refer the reader to [23].
(securityLevel = SAFE) and (isRunningNow = TRUE) first description/notation = "CCM-softpkg" and ( description/implementation/os/name="WinNT" or description/implementation/os/name="Solaris" ) vendor/address/country = "Spain"
4.1.4 Marketing Information Finally, other non-technical details of the service and the component implementing it are described in this section. Typical information described here include licenses, certificates, vendor information, etc.
The first section (COTSdescription) describes the target service, using the previously described COTScomponent template. The client will fill in the required values (interfaces and properties) that will be used to compare against the information available in the service exports that the trader knows about.
05-10-2001 E-Brokering corp. http://www.e-B.com/
[email protected] 04120 Ctra Sacramento s/n Almeria Spain A one-place buffer
interface OnePlaceBuffer { void write(in int x); int read(); }; xsd:string xsd:boolean
It is worth noticing the tag, which allows old service offers to be readily purged.
4.2. Importing Services (looking for components) Once we have described how to document component services, in this section we will discuss how to import them. In order to import a service, in our approach the client needs to provide two XML documents. The first one contains the selection criteria to be used by the trader to look for the service, and points to the second document, which describes the main features of the required service. The selection criteria is described an XML document called COTSquery. It consists of five main parts, as shown below.
The last four parts of COTSquery XML document describe the selection criteria to be used. With regard to the functional aspects of the component, apart from the services description, the required kind of matching in each case can also be specified. The client may specify whether the matchmaking process should be exact or soft, and optionally the matchmaking program to be used (in that case, the program originally stated in the target COTS component description is ignored). We have differentiated between two kinds of matchings: exact (6E ), and soft (6S ). Exact matching is the usual one:
6
given two interfaces A and B , we shall say that A 6E B if A can replace B , i.e., if A is a subtype of B using the common subtyping relations for interface signatures [15, 32]. This operator can also be naturally extended to deal with the semantic descriptions of components, following the usual subtyping relations for pre-post conditions [2, 10, 16, 33], or for protocols [7, 21]. On the other hand, soft-matchmaking between interfaces is defined to be used when trying to make partial matches. At the signature level we shall say that A 6S B if interface B “contains” some of the services defined in A, and we shall also write A ∩ B = 6 ∅. For space reasons we will not formally specify this relation, which is the subject of a forthcoming paper. However, it intuitively means that B offers at least one of the methods required by A. The extension of this operator to deal with semantic information is due to Rym Mili et al. [19], who also define semantic distances between component specifications. Property-based matching is done in the usual way for ODP traders, using constraints and preferences. Constraints are boolean expressions consisting of service property values, constants, relational operators (=, =, !=), logical operators (not, and, or) and parenthesis, that specify the matching criteria for including a component in the trader’s list of candidates for the current search. Constraints are evaluated by the trader by substituting the property names with their actual values, and then evaluating the logical expression. Components whose constraint evaluates to false are discarded. In the example, we have used the notation defined in the W3C’s XML QueryAlgebra proposal for writing the expression (http://www.w3.org/TR/query-algebra/). Preferences allow sorting the list of candidates according to a given criteria, which is expressed using the terms first, random, min(expr) and max(expr), where expr is a simple mathematical expression involving property names [15]. Finally, packaging and marketing information is matched using expressions that relate the values in the appropriate tags ( or ) of the COTSdescription query. In this example, the notation defined in the W3C’s QueryAlgebra proposal is used again for building the “select” expressions.
vices to COTStrader in two different ways: (a) Following a push model, the XML document describing the services provided by the component can be directly registered at the COTStrader. The exporter should know how to reach the trader, which provides an operation to register (i.e, export) new services. (b) Following a pull model, the exporter should only leave the XML document in a place accessible to search engines, that will be continuously used by the trader for discovering new services. Automated searchers (bots) that go through known Web locations looking for service templates can also be used by the trader as well. Our current prototype of COTS trader is implemented as a CORBA object with the following interface: interface COTStrader { boolean export(in string XMLCOTScomponentTemplate); string import(in string XMLCOTSqueryTemplate, in int MaxCandidates, in boolean StoreAndForward); };
The first one registers a service, and returns TRUE if the operation succeeds, FALSE if it fails (in case the XML template is incorrect, for instance). The second operation accepts a COTSquery template as described in section 4.2, and returns a string that contains a sequence of COTScomponent templates, one for each exporter candidate found. The other two parameters allow the user to set the maximum number of candidates to be returned, and whether an ‘store-and-forward’ policy is to be followed. Other parameters and methods offered by the interface are not listed here for space reasons. This CORBA interface is the one that can be directly used by importers and exporters to query and register their services, respectively, if they follow a push model. But together with the basic trader we also have another component, called the ServiceFetcher, which uses well-known search engines for locating Web pages that contain XML descriptions of services, i.e., COTScomponent templates. Once found, they are registered at the COTStrader. This implements a pull model of service exportation, in addition to the push model supported by the CORBA component. Our current implementation just keeps a database with the XML registered templates, that serves as its repository. In this sense, it is just a prototypal implementation to validate the feasibility of our proposal. There are many issues that we would like to explore further, that will be discussed later in section 6.
4.3. The trading process COTStrader is an implementation of a trading service that provides a mapping between a client’s query (an import operation) and a set of COTS components that may act as valid service providers for that query (exporter candidates). We have already discussed the notation for exporting and importing services, by means of XML documents. In this section we will discuss the trading process. In the first place, COTS vendors may export their ser-
5. Related Work Most of existing work on traders (e.g. [4, 5, 22, 11, 17, 24, 26]) follow the ODP model [15] (which is the one also 7
adopted by the OMG), and therefore have similar features, advantages and disadvantages, as we have already discussed in section 2.2. An approach that somehow differentiates from the rest, and claims that an enhanced model for trading is needed for Internet-based software development is WebTrader [31]. This proposal uses XML for describing component services, but the problem is that the information it manages about components is too limited (actually, it is very close to the information handled by the standard ODP trader). On the other hand, S. Terzis and P. Nixon [28] also claimed that trading based on signatures was not enough, and that some sort of ‘semantic’ trading was needed. However, apart from mentioning the requirements for such a trading, no specific proposal was made in their paper. With regard to the documentation of components, this is currently a hot topic, and many authors are proposing different documentations. To mention just a few, IBM is working on a proposal for documenting their large grained components (http://www.ibm.com/software/components), and there are several nice proposals from SEI (http://www.sei.cmu.edu/) claiming better component documentation. Jun Han [13] has defined some component specification templates in a joint project with Fujitsu Australia, which provide semantic information for proper usage and selection of components, on top of their standard signature description. Cho [8], Bastide and Sy [3], and Canal et al. [6] are among the authors that propose IDL extensions for dealing with protocol information, using state transitions, Petri nets, and πcalculus, respectively. Finally, J. Castro et al. [1] are working at the non-functional side of components, trying to add this kind of information to commercial components, with the goal of relating it to the architectural specification of the applications, too. Our proposal for documenting components just tries to provide a common template to integrate most of these different notations, aiming at being flexible and versatile enough for hosting them all.
in section 2.1. However, other issues are still open, such as dynamic service composition and adaptation, the definition and usage of heuristic functions, or query delegation. ‘Semantic’ trading [28] is not covered by our proposal either, since we do not deal with concepts, ontologies or knowledge based trading. On the other hand, our current implementation is just a prototype for validating our ideas, which we are planning to extend in several ways. For instance, we want to integrate it with existing CORBA traders, building bridges to them. We also want to extend the searching capabilities of the ServiceFetcher component so it can use bots and meta-search engines. Finally, we want to develop different front-ends to the trader, so it can offer more user-friendly interfaces to users and software vendors, and even serve as an exporter to other traders.
References [1] C. F. Alves, N. S. Rosa, P. R. F. Cunha, J. F. B. Castro, and G. R. R. Justo. Using non-functional requirements to select components: A formal approach. In Proc. of the Fourth Iberoamerican Workshop on requirements Engineering and Software Environments (IDEAS’01), San Jos´e, Costa Rica, Apr. 2001. [2] P. America. Designing an object-oriented programming language with behavioral subtyping. In J. der Bakker, W. de roever, and G. Rozenberg, editors, Foundations of Object-Oriented Languages, 1990 REX School/Workshop, Noordwijkerhout, The Netherlands, number 489 in LNCS, pages 60–90. Springer-Verlag, 1991. [3] R. Bastide, O. Sy, and P. Palanque. Formal specification and prototyping of CORBA systems. In Proceedings of ECOOP’99, number 1628 in LNCS, pages 474–494. Springer-Verlag, 1999. [4] M. Bearman. Tutorial on ODP Trading Function. Faculty of Information Sciences Engineering. University of Canberra. Australia, 1997. [5] A. Beitz and M. Bearman. An ODP trading service for DCE. In Second International Workshop on Services in Distributed and Networked Environment, 1995. [6] C. Canal, L. Fuentes, J. M. Troya, and A. Vallecillo. Extending CORBA interfaces with π-calculus for protocol compatibility. In Proc. of TOOLS Europe 2000, pages 208–225, France, June 2000. IEEE Press. [7] C. Canal, E. Pimentel, and J. M. Troya. Compatibility and inheritance in software architectures. Science of Computer Programming, 2001. (Accepted for publication). [8] I. Cho, J. McGregor, and L. Krause. A protocol-based approach to specifying interoperability between objects. In Proceedings of TOOLS’26, pages 84–96. IEEE Press, 1998. [9] L. Chung, B. A. Nixon, E. Yu, and J. Mylopoulos. NonFunctional Requirements in Software Engineering. Kluwer Academic Publishers, 1999. [10] K. K. Dhara and G. T. Leavens. Forcing behavioral subtyping through specification inheritance. In Proceedings of
6. Conclusions and future work Although trading has attracted a lot of attention in recent years, specific solutions for Internet-based component trading have not yet been proposed. Our approach tries to enhance the current ODP trading model with those features that will enable an effective COTS component trading in open systems. Of course, there are still many open issues. In the first place, we need to work more on the precise definition of the “6” and “∩” operators for matchmaking, and on their automation in some cases. There are several tools available for particular formal notations, but they still need to be properly connected to the Internet so they can be easily used by the COTStrader as Internet resources. Our proposal covers many of the requirements described 8
[11] [12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23] [24]
[25] [26]
[27] [28]
the 18th International Conference on Software Engineering (ICSE-18), pages 258–267, Berlin, Germany, 1996. IEEE Press. Distributed Object Group. JavaORB. http://www.multimania.com/dogweb, 2001. D. Garlan, R. Allen, and J. Ockerbloom. Architectural mismatch: Why reuse is so hard. IEEE Software, pages 17–26, Nov. 1995. J. Han. Temporal logic based specifications of component interaction protocols. In J. Hern´andez, A. Vallecillo, and J. M. Troya, editors, Proc. of the ECOOP’2000 Workshop on Object Interoperability (WOI’00), pages 43–52, June 2000. L. Iribarne and A. Vallecillo. Searching and matching software components with multiple interfaces. In Proc. of the TOOLS Europe’2000 Workshop on Component-Based Development, France, June 2000. http://www.lcc.uma.es/∼av/Publicaciones/00/cbdtools.pdf. ISO/ITU-T. Information Technology - Open Distributed Processing - ODP trading function. Rec. ISO/IEC DIS 13235, ITU-T X.9tr, ISO, Feb. 1996. G. T. Leavens and M. Sitaraman, editors. Foundations of Component-Based Systems. Cambridge University Press, 2000. M. Merz, K. Muller, and W. Lamersdorf. Service trading and mediation in distributed computing systems. In 14th International Conference on Distributed Computing Systems, pages 450–457. IEEE Computer Society Press, 1994. H. Mili, F. Mili, and A. Mili. Reusing software: Issues and research directions. IEEE Trans. Softw. Eng., 21(6):528– 562, June 1995. R. Mili, J. Desharnais, M. Frappier, and A. Mili. Semantic distance between specifications. Theoretical Comput. Sci., 247(1-2):257–276, Sept. 2000. C. Ncube and N. Maiden. COTS software selection: The need to make tradeoffs between system requirements, architectures and COTS components. In COTS workshop. Continuing Collaborations for Successful COTS Development, 2000. O. Nierstrasz. Regular types for active objects. In O. Nierstrasz and D. Tsichritzis, editors, Object-Oriented Software Composition, pages 99–121. Prentice-Hall, 1995. Object Oriented Concepts. ORBacus trader. ORBacus for C++ and Java. Technical report, Object Oriented Concepts (OOC), Inc., 2000. http://www.ooc.com/ob. OMG. The CORBA Component Model. Object Management Group, June 1999. http://www.omg.org. PrismTech. Trading service - white paper. PrismTech OpenFusion, Enterprise Integration Services, January 2001. http://www.prismtecnologies.com. S. Robertson and J. Robertson. Mastering the Requirement Process. Addison-Wesley, 1999. D. C. Shmidt. AceORB (TAO). the Adaptative Communication Environment. http://www.cs.wustl.edu/∼schmidt/ACE, 2001. C. Szyperski. Component Software. Beyond ObjectOriented Programming. Addison-Wesley, 1998. S. Terzis and P. Nixon. Semantic trading: Tackling interoperability problems during systems integration. In A. Vallecillo, J. Hern´andez, and J. M. Troya, editors, Proc. of the
[29]
[30]
[31]
[32]
[33]
9
ECOOP’99 Workshop on Object Interoperability (WOI’99), pages 35–42, June 1999. V. Tran and T. Liu. A procurement-centric model for engineering component-based software systems. In Proc. of the Fifth International Symposium on Assesment of Software Tools, June 1997. A. Vallecillo, J. Hern´andez, and J. M. Troya. Object interoperability. In Object-Oriented Technology: ECOOP’99 Workshop Reader, number 1743 in LNCS, pages 1–21. SpringerVerlag, 1999. V. Vasudevan and T. Bannon. Webtrader: Discovery and programmed access to web-based services. In Poster at the 8th International WWW Conference (WWW8), Toronto, Canada, May 1999. http://www.objs.com/agility/techreports/9812-web-trader-paper/WebTraderPaper.html. A. M. Zaremski and J. M. Wing. Signature matching: A tool for using software libraries. ACM Trans. on Software Engineering and Methodology, 4(2):146–170, Apr. 1995. A. M. Zaremski and J. M. Wing. Specification matching of software components. ACM Trans. on Software Engineering and Methodology, 6(4):333–369, Oct. 1997.
