FRINK Linked Data Fragments server

Matches in SemOpenAlex for { <https://semopenalex.org/work/W1555984907> ?p ?o ?g. }

• W1555984907 endingPage "28" @default.
• W1555984907 startingPage "24" @default.
• W1555984907 abstract "Distributed applications are challenging since they often involve many different protocols. Adaptability is then hard to achieve because of complex protocol dependencies. Having experienced such complexity, we come to the conclusion that object-orientation is of no use if good abstractions have not been defined first. We claim that protocols as objects should be the basic structuring elements from which distributed applications are built. 1 Distributed programming: in search of the Holy Grail Building distributed applications is difficult because one has to deal with many complex issues, e.g., reliable communications, failure detections, distributed agreement, each of which can be seen as a particular distributed protocol. In this context, adaptability is often hampered by complex interactions between the various protocols involved: nobody knows what is going to happen if something is altered in the equilibrium of interdependent protocols. 1.1 Need for right abstractions Programmers of distributed applications have to make their way across the protocol “jungle”, in order to choose the right set of solutions for their problems. Furthermore, when some existing distributed application has to be adapted to ne w requirements, one has first to understand what protocols are involved and how they cooperate. Having experienced such situations with the GARF [6] and the PHOENIX [2] systems, we have drawn the conclusion that the object-oriented technology is not of great help if the right abstractions have not been pre viously defined, i.e., abstractions that are equally basic, simple, few, yet po werful and flexible. Several abstractions have already been described in the literature for structuring distributed applications, but we think none has fully succeeded in bringing power and simplicity, together with adaptability. , Pascal Felber and Rachid Guerraoui 2 Existing approaches do not place the emphasis on protocols as basic structuring components of distributed applications, and many do not even consider reliability issues. This is rather surprising, since our experience taught us that distributed systems are indeed subject to failures, and that protocols are everywhere in distributed applications: any type of communication implies a protocol and there are many, e.g., pointto-point, multicast, reliable, unreliable, fifo, totally ordered, causally ordered, groupbased, RPC-like, etc. Besides, there are lots of other distributed interactions that can be seen as protocols: distributed agreement, failure detections, transactions, etc. Distributed applications usually involve more than one protocol, so the problem of their composition comes next. We claim that there is the need for more basic, yet powerful and flexible abstractions, and that protocols should be the fundamental structuring abstractions of distributed applications. By using protocols as basic structuring components, protocol composition, which is at the heart of adaptability issues, is made easier. 2 Adaptability through protocol classes One can view distributed protocol as a set of interactions between distrib uted objects that are aiming at solving some problem . We define protocol class Object as a class of distributed objects capable of participating in protocol , and we refer some instance a Object as a protocol object. The advantage of such broad definitions is that they cover almost any object interaction involved in a distributed application, while being simple. In BAST, the root of the protocol class hierarchy is abstract class Protobject. Protocol classes help to reuse complex distributed algorithms, e.g., the distributed consensus algorithm described by Chandra and Toueg [1] is implemented, once and for all, in a reusable class. They also help to understand relationships between distributed algorithms, by providing a modular view of distributed protocols; making different protocols work together is then made easier . Subclassing, allows to customize and/or optimize existing protocols, and to create new ones with minimal efforts. As a consequence, adaptability is made a lot easier, because all distributed protocols involved in an application are known, as well as their interactions: we are no more in a situation where nobody knows what is going to happen if parts of the application are adapted to new requirements. Figure 2-1 (a) presents some protocol dependencies. Right Abstractions on Adequate Frameworks for Building Adaptable Distributed 3 Fig. 2–1 Protocols and protocol classes 3 Our tentative framework With BAST, we have tried to build an adequate framework for supporting protocols as classes of objects, and for f acilitating protocol compositions. BAST's protocol class hierarchy enables to structure distributed applications according to their needs in protocols: applications are made of protocol objects, which act as distributed entities capable of executing one or more protocols. So, the programmer's task merely comes down to choose the right protocol class for the right problem, and to customize it. In BAST, distributed protocols are said to be generic. This genericity implies that the type of arguments passed to any protocol operation is not restricted, and that callback operations are supposed to be redefined by each application. Figure 2-1 (b) illustrates part of BAST's protocol class hierarchy: each protocol class corresponds to some protocol of figure 2-1 (a). 3.1 From inheritance to the Strategy design pattern As far as distributed application design is concerned, inheritance is an appropriate tool: by passing appropriate arguments to protocol operations and by implementing callback operations according to their semantics, application programmers have the ability to tailor generic protocol classes to their needs. However, we claim that inheritance alone is not sufficient as far as protocol composition goes, because it does not offer enough flexibility. For example, inheritance does not allow to easily implement a new algorithm for some existing protocol and to use it in whatever protocol class we want. Furthermore, inheritance is not appropriate when it comes to choose among several protocol algorithms at runtime. As a consequence, adapting existing applications is made difficult as soon as protocols needed by new requirements are not available from the BAST library, i.e., when they first have to be implemented by composing existing ones. These limitations lead us to seek an alternative solution, based on disunreliable message passing reliable message passing" @default.
• W1555984907 created "2016-06-24" @default.
• W1555984907 creator A5003921716 @default.
• W1555984907 creator A5039003830 @default.
• W1555984907 creator A5049321288 @default.
• W1555984907 date "1997-01-01" @default.
• W1555984907 modified "2023-10-18" @default.
• W1555984907 title "Right Abstractions on Adequate Frameworks for Building Adaptable Distributed Applications" @default.
• W1555984907 cites W1516219457 @default.
• W1555984907 cites W1585644845 @default.
• W1555984907 cites W1649645444 @default.
• W1555984907 cites W2025306105 @default.
• W1555984907 cites W2133943294 @default.
• W1555984907 cites W50163647 @default.
• W1555984907 hasPublicationYear "1997" @default.
• W1555984907 type Work @default.
• W1555984907 sameAs 1555984907 @default.
• W1555984907 citedByCount "0" @default.
• W1555984907 crossrefType "journal-article" @default.
• W1555984907 hasAuthorship W1555984907A5003921716 @default.
• W1555984907 hasAuthorship W1555984907A5039003830 @default.
• W1555984907 hasAuthorship W1555984907A5049321288 @default.
• W1555984907 hasConcept C10138342 @default.
• W1555984907 hasConcept C111472728 @default.
• W1555984907 hasConcept C120314980 @default.
• W1555984907 hasConcept C138885662 @default.
• W1555984907 hasConcept C142724271 @default.
• W1555984907 hasConcept C151730666 @default.
• W1555984907 hasConcept C154945302 @default.
• W1555984907 hasConcept C15569618 @default.
• W1555984907 hasConcept C162324750 @default.
• W1555984907 hasConcept C177264268 @default.
• W1555984907 hasConcept C177606310 @default.
• W1555984907 hasConcept C18903297 @default.
• W1555984907 hasConcept C199360897 @default.
• W1555984907 hasConcept C204787440 @default.
• W1555984907 hasConcept C2775945657 @default.
• W1555984907 hasConcept C2779343474 @default.
• W1555984907 hasConcept C2780385302 @default.
• W1555984907 hasConcept C2780586882 @default.
• W1555984907 hasConcept C2781238097 @default.
• W1555984907 hasConcept C41008148 @default.
• W1555984907 hasConcept C49312422 @default.
• W1555984907 hasConcept C71924100 @default.
• W1555984907 hasConcept C81192388 @default.
• W1555984907 hasConcept C86803240 @default.
• W1555984907 hasConceptScore W1555984907C10138342 @default.
• W1555984907 hasConceptScore W1555984907C111472728 @default.
• W1555984907 hasConceptScore W1555984907C120314980 @default.
• W1555984907 hasConceptScore W1555984907C138885662 @default.
• W1555984907 hasConceptScore W1555984907C142724271 @default.
• W1555984907 hasConceptScore W1555984907C151730666 @default.
• W1555984907 hasConceptScore W1555984907C154945302 @default.
• W1555984907 hasConceptScore W1555984907C15569618 @default.
• W1555984907 hasConceptScore W1555984907C162324750 @default.
• W1555984907 hasConceptScore W1555984907C177264268 @default.
• W1555984907 hasConceptScore W1555984907C177606310 @default.
• W1555984907 hasConceptScore W1555984907C18903297 @default.
• W1555984907 hasConceptScore W1555984907C199360897 @default.
• W1555984907 hasConceptScore W1555984907C204787440 @default.
• W1555984907 hasConceptScore W1555984907C2775945657 @default.
• W1555984907 hasConceptScore W1555984907C2779343474 @default.
• W1555984907 hasConceptScore W1555984907C2780385302 @default.
• W1555984907 hasConceptScore W1555984907C2780586882 @default.
• W1555984907 hasConceptScore W1555984907C2781238097 @default.
• W1555984907 hasConceptScore W1555984907C41008148 @default.
• W1555984907 hasConceptScore W1555984907C49312422 @default.
• W1555984907 hasConceptScore W1555984907C71924100 @default.
• W1555984907 hasConceptScore W1555984907C81192388 @default.
• W1555984907 hasConceptScore W1555984907C86803240 @default.
• W1555984907 hasLocation W15559849071 @default.
• W1555984907 hasOpenAccess W1555984907 @default.
• W1555984907 hasPrimaryLocation W15559849071 @default.
• W1555984907 hasRelatedWork W101350099 @default.
• W1555984907 hasRelatedWork W1540712843 @default.
• W1555984907 hasRelatedWork W1540761544 @default.
• W1555984907 hasRelatedWork W1603662494 @default.
• W1555984907 hasRelatedWork W2090461050 @default.
• W1555984907 hasRelatedWork W2101534265 @default.
• W1555984907 hasRelatedWork W2106952920 @default.
• W1555984907 hasRelatedWork W2117083954 @default.
• W1555984907 hasRelatedWork W2128804127 @default.
• W1555984907 hasRelatedWork W2129328709 @default.
• W1555984907 hasRelatedWork W2131603858 @default.
• W1555984907 hasRelatedWork W2141716967 @default.
• W1555984907 hasRelatedWork W2144092942 @default.
• W1555984907 hasRelatedWork W2155771481 @default.
• W1555984907 hasRelatedWork W2163560697 @default.
• W1555984907 hasRelatedWork W2164232748 @default.
• W1555984907 hasRelatedWork W2220748953 @default.
• W1555984907 hasRelatedWork W2366610553 @default.
• W1555984907 hasRelatedWork W2545309569 @default.
• W1555984907 hasRelatedWork W2546262199 @default.
• W1555984907 isParatext "false" @default.
• W1555984907 isRetracted "false" @default.
• W1555984907 magId "1555984907" @default.
• W1555984907 workType "article" @default.