Trading for COTS components in open environments - CiteSeerX

Trading for COTS components in Open Environments Jos6 M. Troya and Antonio Vallecillo University of MBlaga ETSI Informiitica. 2907 1 MBlaga, Spain {troya,av} @Icc.uma.es

Luis Iribarne University of Almeria Escuela Polittcnica. 04120 Almeria, Spain liribarne @ual.es

Abstract

shift from a development-centric towards a procurenietitcentric approach [25],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 [ 1 I , 191.

Trading is a well-known niechatiisni for searching and locating services in ohject-oriented systenis. Howevel; e11rretit traders present sonie limitations when used in open component-based system environnients. In this paper w e analyze the required features that COTS conipotients traders should have, ancl describe the desigti arid iniplementatioti of COTStradel; an Internet-based trader for COTS conipotierits that hatidles the heterogetieity scalability unci evolution of COTS markets.

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 [%I, or non-functional requirements [ 1, 71. 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 [27].

1. Introduction In the last decade, Conipotietit-Based Sojt\vare Engineering has generated tremendous interest due to the dcvelopment of plug-and-play reusable software, which has led to the concept of ‘commerciul off--the-shelf’ (COTS) software components. Although currently more a goal to pursue a than a reality, this approach moves organizations from application cievelopnient to application assenibly. 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 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 not transferable to component-based development. In CBSE the system designer also has to take into account the specification of pre-developed COTS components that may exist in software repositories, when building the initial system’s requirements in order to incorporate them into all phases of the development process [ 17, 221. There is significant

1089-6503/01$10.30 0 2001 IEEE

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 iniprove 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.

30

2. Requirements for a COTS trader

of) the traders they federate with. Although a very secure and controlled scheme, the communication overhead grows with the number of federated traders. In the repository-bused federation, multiples traders read and write to the same service repository; traders are not directly aware of each other, so this approach is scalable., The problem is the implementation of a globally accessible repository. However, this is not an issue in the Internet, 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. 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 selfconfiguring 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 [23]. 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.

4. Service composition and adaptation. Current traders

focus on one-to-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. In addition, one-to-one exact matchmaking is also inadequate in a number of situations, e.g., when, format, QoS, or performance mismatches happen between the client and the closest matching service instance. This problem can be addressed by composing such a service instance with format translators and performance monitors to reduce mismatches.

5. Multiples interfaces. In object-oriented systems, services are described by interfaces, and each object provides just one interface (although it may be obtained from many by 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 [ 131.

2.1. Wish-list 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 accommodate to the evolution of the current models, and to new ones as soon as they appear.

6. 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.

2. 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 domain-specific property space, in contrast to (rather, in addition to) the keyword-based, domain-neutral matchmaking supported by document search engines.

7. 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. 8. 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

3. Federation. Cooperating traders can federate using different strategies. The direct federation approach requires traders to directly communicate to (and know




. . . . . _ c/providedInterfaces> . . . . .

Once we have identified the requirements for a COTS components trader in open systems, 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 cornponents (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 w r i te ( ) . 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 processcs, and the way the trader works, all within the restricted space of this paper. This example is available at

_

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 services to be called, and the order it call other components' methods. In our example, the first section is described as: interface OnePlaceBuffer ( void write(in long x ) ; long read(); ) ; _ _ Larch . here . . . csoftMatching href= " . . . /larch/softMatch.cgi"/>

http://www.cotstrader.com/.

4.1. Exporting services (documenting components) For the description of a COTS component we have designed some DTD templates based on the W3C's XMLSchema schema language. The following shows a simple instance skeleton of the template of scheme designed for the case of the OnePlaceBuf fer component.