Development of Distributed Applications with Separation of Concerns Antonio´ Rito Silva, Pedro Sousa and Jose´ Alves Marques IST/INESC, R. Alves Redol no 9, 1000 Lisboa, PORTUGAL Tel: +351-1-3100287 – Fax: +351-1-525843 email: [email protected] 7th ERCIM DBRG Workshop on Object-Oriented Databases. INESC - Lisbon, Portugal. May, 15-16, 1995. Abstract transparency: failure, access, location, concurrency, replication, migration, performance, and scaling [11]. These researchers do not agree on the need of full The development of distributed applications is an open transparency, raising two questions: Is it possible to area involving researchers from different communities. We achieve? Is it worthwhile? Nevertheless, with trans- propose an object-oriented approach to the development parency, developers needn’t concern themselves about of distributed applications emphasizing separation of distribution issues, since the platform encapsulates concerns. Our approach combines the needs of transparen- them. cy, encapsulation of distribution issues, and support of non-traditional models, where cooperation and sharing The obvious advantages of transparency have are needed. The development process is constructive, however some drawbacks: absence of detail and lack thus allowing partial verification of results. We recognize ofsupportfornontraditionalmodels[32]. Inmostsys- seven concerns: fragmentation, replication, naming, tems, transparency does not allow distributed issues concurrency, failure, configuration, and communication. to be handled at different levels of abstraction, accord- Each concern is perceived in three levels of abstraction: ing to the particular application needs. Moreover, only models, policies and mechanisms. Besides a development traditional application models are supported by such centered on separation of concerns we propose another systems. It is hard to support new emerging areas, as process centered on development stages. Both, concerns cooperative work, where those models are relaxed. and stage perspectives, are part of an integrated and flexible development process. Our approach combines the advantages of trans- parency and the support of non-traditional models. Keywords: Distributed Systems and Architectures, Furthermore, development can be done at different Object-Oriented Analysis and Design. levels of abstraction. We propose a constructive development with sep- aration of concerns. Applications are developed in a 1 Introduction stepwise manner, handling one concern at a time. One of our environment’s key features is the independence between solutions for each concern, allowing trans- Sequential applications in a centralized system use tra- parency in all issues but the one being solved. So- ditional models where activities and data are isolated. 1 lutions of concerns do not interfere , although some In distributed systems activities and data are intrin- combinations may not be possible. Furthermore, a sically distributed and shared. Distribution yields a functionality-centered process is also described and model inherently more complex, thus making appli- consistently integrated with the concerns perspective. cation development a difficult task. Transparency, of- Verification and debug are also stepwise processes. fering in a distributed system the same model that cen- Default solutions are offered to achieve a rapid devel- tralized systemsoffer, has been the goal of researchers. opment and support for traditional models. We offer Distributed operating systems and platforms [29, 1 In section 4 we explain what is meant by non-interference. 6] have been proposed offering several degrees of 1 tools which incorporate default solutions, allowing a Replication. Some distributed applications transparent development. need to replicate information because of both availability and reliability. Availability permits Concerns are perceived in three levels of abstrac- access to replicated information without remote tion: models, policies and mechanisms. Solutions for accesses. Reliability hides failures of remote each one of these levels are considered in the construc- nodes from the local computation. The replica- tion of each concerns’s solution. This approach allows tion concern defines replica objects that are dis- several independence levels and, so, an uniform devel- tributed between worlds and together behave opment of heterogeneous applications: heterogeneity consistently as a unique object. The replication of policies and mechanisms. The mechanism level of concern should preserve some kind of object con- abstraction can be implemented over heterogeneous sistency. languages and machines. Naming. Distributed applications use different Our approach follows the object-oriented analy- name spaces and so the meaning of a name de- sis and design paradigm. Other object-oriented ap- pendents on a particular name space context. proaches, e.g. [33, 18, 4, 9], have as yet not addressed Furthermore, names can have different proper- distribution issues in depth. ties depending on the name space they belong to, e.g. location transparency, where the name does The rest of this paper is structured as follows. Dis- not restrict the location of the named object to a tribution concerns are described in section 2. In section particular node. The naming concern defines the 3 abstraction levels are introduced. The development name spaces needed for the distributed applica- process either centered on concerns or on stages is tion such that names coexist consistently in the described in sections 4 and 5, respectively. Section 6 application, e.g. different name spaces sharing a describes the concurrency concern in depth. Relat- name. ed work is presented in section 7 and conclusions in section 8. Concurrency. Shared access to resources is a feature of distributed applications. Applications must generate and control the concurrency with- in a resource. Concurrency control has sev- 2 Concerns eral properties, e.g. it may be transparent in the sense that users do not cooperate when ac- Designing distributed applications involves the solu- cessing the resource. The concurrency concern tion to particular problems. Each one of these prob- should define concurrency generation and con- lems is a development process concern. We have rec- trol. The former creates and destroys activities. ognized seven main concerns which we believe cover Concurrency control constrains undesirable in- most distribution issues: fragmentation, replication, teractions. naming, concurrency, failure, configuration, and com- Failure. In distributed systems, applications munication. are likely to fail and the robustness degree de- pends on application semantics. Failures can be Fragmentation. A distributed application masked from the user. The failure concern de- schema is the composition of several schemas fines the desired degree of robustness and guar- that together constitute the application schema2 . antees that it is achieved. When designing distributed applications using Configuration. During an application’s lifetime our approach, application functionalities are iso- worlds can be created and destroyed. Upon cre- lated in different logical distribution units, re- ation, worlds and their objects, need to be inte- ferred to as worlds. The fragmentation con- grated within the application, and, after a world cern is about the definition of worlds and their is destroyed, the application should adapt it- schemas such that application semantics results self to the new configuration. Several kinds of from the semantics of the different worlds. For configurations are possible: static configuration, instance, in a bank’s distributed database sys- where inter-world relationships are hard-coded; tem, client accounts are stored in the local or dynamic configuration, where inter-world re- database branch where the account was open. lationships can change at run-time. The config- In the example, each local database branch is a uration concern defines how worlds and their world and the client account is fragmented in the objects react upon creation and destruction of different worlds. other worlds. For instance, when a server is shut 2 We use schema to denote both static and dynamic structure of down, client nodes must send requests to anoth- applications. er server. 2 Communication. Worlds in a distributed appli- of models and policies and are platform independent. cation can communicate using different commu- Concrete mechanisms are the actual platform mech- nication paradigms as, for instance, procedure anisms and are used to implement abstract mecha- call or mailboxes. These paradigms have dif- nisms. Abstract mechanisms should be expressive ferent communication models and different in- enough to support policies and simple enough to be vocation syntax. The communication concern implemented by platform mechanisms. Due to their defines the communications paradigms the ap- proximity to platform mechanisms, the same abstract plication uses and integrates them within the ap- mechanism can be used in the implementation of dif- plication, e.g., asynchronous communication is ferent concerns policies. related with the concurrency concern. Consider, as an example, the concurrency concern which is divided in concurrency generation and con- The degrees of transparency referred to in sec- currency control. A possible model of concurrency tion 1 [11] are obviously related to distribution con- generation is one in which the user is not aware of cerns since they intend to make development easier