Constraint-based Generation of Connectors

Transcription

1 Constraint-based Generation of Connectors Tomas Bures Charles University, Faculty of Mathematics and Physics, Prague, Czech Republic Abstract. In this paper we discuss the a typical use-case of connector usage in component-based systems. We show how the connectors are refined during application development and investigate a way how to automatically generate connectors with respect to style of interaction and component distribution. 1 Introduction The connector as a first class entity emerged in component models in recent years to represent communication among components. Its responsibilities vary a lot from model to model. Component systems employing connectors can be basically divided into two branches. The first understand a connector only as a design element which allows to describe and restrict the mediated communication. To the representatives of this approach belong: Wright [1], ACME [5], which use CSP to define the communication protocol; Aster [3], which employs temporal logic for the same task; and SADL [8] which uses a sort of constraint language. These models usually do not deal with connector implementation. The other understand a connector as an implementation element which performs a real functionality at runtime. To these systems belong: UniCon [13], which, however, offers only a set of predefined connectors (Pipe, FileIO, ProcedureCall, RemoteProcedureCall, DataAccess, RTScheduler, and PLBundler); and JavaPod [12] which creates connectors by wrapping (similar to protocol stack) and thus understands connectors only as a sort of filters. 2 Goals and structure of the paper In order to ease development of connector-based component applications, in this paper we investigate how to create connectors (semi-)automatically. In Section 3 we show a typical use case of connectors explaining connector responsibilities. In Section 4 we summarize desired connector features and refine our goals. Section 5 describes our approach to connector generation, while Section 6 evaluates the results and sketches our future work. 3 Typical use case of connectors Similarly to component-based applications without connectors, there are three basic development phases design, implementation and deployment. (A) In design phase, basic blocks of the application are identified; the application is broken into independent pieces of functionality (components); and ways of interaction between single components are defined. The interaction is described by definition of provided and required interfaces and the Figure 1 Media Player

2 communication style (procedure calls, events, shared memory, etc.) The result of the design phase is demonstrated in Figure 1, which shows an example of a simple media player. The figure consists of four components (Reading Unit, Controller, Display, and Speaker). The Reading Unit is a component that reads data from a stream, decodes them and sends them to the Speaker component. To control the Media Player, there is a Controller component, which reacts to user interface buttons such as Play', Pause', Stop', etc. There can be several Controller parts (e.g. remotely connected). Current status (played title, track, etc.) is displayed by the Display component, which can also have several instances. The arrows represent component interactions, which can be of various types, as can be seen in the example. The Reading Unit sends the data to Speaker using an unidirectional pipe; the Controller communicates with the Reading Unit via local or remote procedure call; and the connection between the Reading Unit and Display is realized by asynchronous event distribution (messaging). (B) In implementation phase, single components are coded. For communication with other connected components, a component relies only on required (white rectangles) and provided interfaces (black rectangles) on the component boundary and a communication style associated with each link, otherwise is the component independent. That means, a component can be replaced by another which is compatible only on interfaces and communication style. (C) In deployment phase, components are implemented and have to be composed together to form a resulting application. First, components are situated to particular computers (deployment nodes). Components can reside in only one address space or be distributed over network virtually in any way. Then the components requirements (required interfaces) are connected to provisions (provided interfaces) using appropriate connector instance (the rectangles in Figure 1). The connector instance here is chosen with respect to the communication style and environment. E.g. if two components do not reside on same computer, a procedure call connector must have support for marshalling and network transport. Moreover, as the environment can be heterogenous, the connector must be created with respect to the system and middleware present on target computers (e.g. RMI [18] can be utilized only if both components are written in Java) 4 The role of connectors The key point of connector usage is that all communication related code is concentrated in connectors, thus making component code totally distribution independent. Also, a connector functionality can be enriched by additional tasks (e.g. a connector can perform logging, help with debugging, hide minor incompatibilities between components using simple adaptation etc.) As different connectors perform similar tasks, it is possible to generate connector code automatically or at least semi-automatically, which reduces the component-based development only to design and coding of components, leaving deployment (distribution and binding) to a sort of a smart tool. Evaluating the use case and the observation above, we can now list the most important features an ideal connector model should posses: I. Connectors should be first-class design entities [2] capturing all the inter-component communication. II. The model is not too restrictive, allowing for different styles of communication (not only for procedure call) [14, 7]. III. Connectors are reflected in an implementation. They transparently (from components point of view) allow for different non-functional properties [4] (e.g. distribution, security, etc.) IV. Connectors are generated with the least possible user intervention, employing current middleware [5]. The goal of our work is to create such a connector model that would satisfy all the statements above.

3 5 Solution 5.1 The model BURES: CONSTRAINT-BASED GENERATION OF CONNECTORS In our work we follow and extend the connector model proposed by Balek, Plasil in [2]. Connectors (see example in Figure 2) there are composed of smaller parts elements (the circles), which represent single actions. Depending on the way a connector is distributed, the elements are structured into units (dotted lines). Elements in one unit are to reside in the same address space. A binding between elements residing in the same address space is performed by an ordinary function call. A binding between elements distributed across units is performed by the respective elements themselves (allowing to employ different kinds of middleware e.g. CORBA [10], RMI [18], JMS [17], etc.) In more detail, the example in Figure 2 shows a sample remote procedure call (meaning, a procedure call Figure 2 Procedure call gray box view (connector architecture) connector need not be structured exactly in this way). The white and black circles (roles) are in principle generic interfaces of the connector. They are used to bind connector to components. The gray circles represent internal actions. In this example a call emitted from client goes through the crole element to the connector (client unit), there the stub element marhalls parameters and method name and transmits data to the other unit (server unit). There, data are read by the skeleton element, unmarshalled and a resulting call is passed to the logging element. This element logs the call (e.g. to file, console, database, etc.) and passes the call to the srole element, which then invokes the call on an attached component. The result of the function call goes back from server to client through the elements in the reverse order. 5.2 Levels of abstraction In connectors, we recognize four levels of connector abstraction. (The first one is used in design phase; the other three are used in deployment phase, as they need particular information about target deployment nodes): I. On the highest level of abstraction, we view a connector as a kind of communication contract. This level of abstraction defines communication style and connector roles (connector frame), which should be the minimum already sufficient for the application design phase. Currently, with respect to middleware we recognize four communication styles (procedure call, messaging, streaming, and blackboard) [4]. II. On the second level of abstraction, we view a connector as a set of interconnected elements (connector architecture) as depicted in Figure 2. The elements on this level are, however, still generic, later to be implemented by a particular class. III. On the third level of abstraction, particular implementation to every element found in the connector architecture is assigned. Using different implementations allows us to change connector behavior (e.g. to switch between CORBA and SOAP [19] only by exchanging the stub and skeleton element implementations). However the element implementations are still a sort of template, later to be adapted to particular component interfaces. IV. On the lowest level the element implementations are adapted to be able to mediate interfaces of components attached to the connector. At runtime, a connector is instantiated using a connector builder, which reflects the connector architecture (the second level of abstraction), and a set of adapted element implementations (the fourth level

4 Figure 3 Procedure Call connector refinement of abstraction). The connector builder instantiates particular adapted element implementations and binds them together to build respective connector units. 5.3 Automatic generation of connectors The previous section described how connectors are refined from the communication style to the actual connector instance. On the top level lies a decision of a designer. On the bottom level, there is a particular connector instance. On the way, there are three steps that have to be done from the communication style to the connector instance. These steps (see Figure 3) we call connector generation. In the first step, we choose a connector architecture (or better architecture for each connector unit) with respect to communication style and required non-functional properties (e.g. distribution, security, etc.). In the second step, we choose implementation of particular elements in the architecture with respect to the required non-functional properties and features offered by the target platforms (e.g. particular ORB or SOAP implementation, encryption libraries, etc.). Finally, in the third step, we adapt the chosen element implementations to support the interface of the attached component. As each step can be performed in several ways, we get a tree where in the root there is the selected communication and in the leaves there are particular connector implementations that comply with the communication style.

5 This tree can be viewed also as a search tree. Assuming, in each step we have only a limited set of possible options (which is assured by a repository of architectures for connector units, and repository of element implementation templates), we can use back-tracking technique to automatically find proper connector configuration (i.e. connector architecture and element implementations). There are several constraints which must hold to assure the connector configuration is correct. (1) The architecture must reflect the communication style and desired non-functional properties. (2) The connector must be consistent, meaning the chosen element implementations are able to cooperate (e.g. if data are marshalled on client side using CORBA IIOP, they have to be unmarshalled on server side again using CORBA IIOP; the same holds for encryption, transaction propagation, etc.). (3) An element implementation poses requirements on the target dock, where the adapted element implementation should run (e.g. libraries of particular ORB). Having the proper connector configuration, the rest of connector generation is easy. The architecture is used to create a connector builder and the element implementations are adapted to particular component interface. 6 Related and future work To our knowledge, the possibility of connector generation is almost missing in current component-based systems. Similar to automatic creation of connectors is generation of stubs and skeletons in middleware [10, 18, 9], however, this makes the attached components middleware-dependent and supports only procedure call (in some cases also messaging is supported to an extent). In our work we address the connector generation in three steps. The first two comprise selection of particular connector configuration, the third consist of adaptation of selected elements to components interfaces. As a proof-of-the concept, we have implemented a connector generator for SOFA/DCUP [11, 15]. The first and second step, is addressed by a composition checker in Prolog, which traverses the search tree and looks for the suitable connector configurations. The third step (adaptation of primitive templates) [5] is addressed by a Java-implementation of an element adaptor. In this adaptor, each element implementation template is represented by a sort of XML makefile and auxiliary Java-classes. The makefile describes which steps have to be performed in order to adapt the element implementation to a particular interface (e.g. in case of JavaIDL [16] this comprises generation of IDL file, generation of stub and skeleton classes, and compiling them). Our future work comprises further investigation of rules for the first and second step. We created rules for connector consistency checks, however, we need also rulse for checking compliance with desired nonfunctional properties (e.g. distribution, security, etc.) and environment dependencies (a particular library, etc.). References [1] Allen, R. J., Garlan, D.: A formal basis for architectural connection. ACM Transactions on Software Engineering and Methodology, 1997 [2] Balek, D., Plasil, F.: Software Connectors and Their Role in Component Deployment, In Proceedings of DAIS'01, Krakow, Kluwer, September 2001 [3] Blair, G., Blair, L., Issarny, V., Tuma, P., Zarras, A.: The Role of Software Architecture in Constraining Adaptation in Component-based Middleware Platforms, Proceedings of Middleware 2000, IFIP/ACM International Conference on Distributed Systems Platforms and Open Distributed Processing, Hudson River Valley (NY), USA. Springer Verlag, LNCS, April 2000 [4] Bures, T., Plasil, F.: Scalable Element-Based Connectors, Proceedings of SERA 2003, San Francisco, USA, Jun 2003

6 [5] Bulej, L., Bures, T.: A Connector Model Suitable for Automatic Generation of Connectors. Tech. Report No. 2003/1, Dep. of SW Engineering, Charles University, Prague, 2003 [6] Garlan, D., Monroe, R. T., Wile, D.: Acme: Architectural Description of Component-Based Systems. Foundations of Component-Based Systems, Leavens, G., T. and Sitaraman, M. (eds), Cambridge University Press, 2000 [7] Medvidovic, N., Taylor, R. N.: A Classification and Comparison Framework for Software Architecture Description Languages. IEEE Transactions on Software Engineering, Vol. 26, No. 1, January 2000 [8] Moriconi, M., Riemenschneider, R., A.: Introduction to SADL 1.0: A Language for Specifying Software Architecture Hierarchies, Technical Report SRI-CSL-97-01, Mar [9] ObjectWeb Consortium: ProActive manual version 1.0.1, January 2003 [10] OMG formal/ : The Common Object Request Broker Architecture: Core Specification, v3.0, December 2002 [11] Plasil, F., Balek, D., Janecek, R.: SOFA/DCUP: Architecture for Component Trading and Dynamic Updating, Proceedings of ICCDS'98, Annapolis, Maryland, USA, IEEE CS Press, May 1998 [12] Putman, J., Hybertson, D.: Interaction Framework for Interoperability and Behavioral Analyses, ECOOP Workshop on Object Interoperability, 2000 [13] Shaw, M., DeLine, R., Zalesnik, G.: Abstractions and Implementations for Architectural Connections. Proceedings of the 3rd International Conference on Configurable Distributed Systems, May 1996 [14] Shaw, M., Garlan, D.: Software Architecture, Prentice Hall, 1996 [15] The SOFA Project, [16] Sun Microsystems, Inc.: Java IDL, [17] Sun Microsystems, Inc.: Java Message Service, April 2002 [18] Sun Microsystems, Inc.: Java Remote Method Invocation Specification Java 2 SDK, v1.4.1, 2002 [19] W3C: Simple Object Access Protocol (SOAP), v1.1, May 2000