Contract-based Coordination of Distributed Object ... - Semantic Scholar

Contract-based Coordination of Distributed Object Systems Holger Giese, J¨org Graf and Guido Wirtz Institut f¨ ur Informatik Westf¨alische Wilhelms-Universit¨at M¨ unster, GERMANY

Abstract For distributed object or component systems based on CORBA or DCOM, a suitable software architecture and a strong separation of modules is necessary. Our object coordination net approach (OCoN) allows mixed event and state based true concurrent modeling. It describes contracts, object scheduling, resource handling and the abstract data and control flow of services. A seamless integration of contract specifications into service and object scheduling specifications is provided. Although abstract, the OCoN formalism remains operational which permits abstract simulation and a feasible implementation is guaranteed. The paper demonstrates the benefits of contract based coordination with the OCoN approach by means of an extended example. Keywords: object-oriented design , coordination, contracts, distributed systems, Petri-Nets

1

Introduction

Traditional object-oriented design notations and the new UML [1] standard are appropriate and specialized to support programming language based development. But often even in this situation, a seamless transition from the design to the implementation can not be achieved because several technical and behavioral aspects are ignored during the design. Often, a strong separation between the objects is missing, which leads to unexpected dependencies and results in severe problems during the implementation. Lacking separation becomes even a bigger drawback when the sys-

tem evolves and the size of the system grows or when sub-systems are distributed using middleware approaches like CORBA [2] or DCOM [3]. For such systems a higher emphasis on a sufficient software architecture [4] including a stronger need for separation is essential. We reflect this additional requirement by putting a strong emphasis on the basic software engineering ideas of modularization as well as separation and by applying the ”design by contract” idea of Meyer [5]. A separation of independent contracts as in role based modeling [6] and thus the support of multiple interfaces for different concerns as outlined in [7] is necessary. The combination of the usual syntactical interface notion with a behavioral protocol builds a basic contract that allows to reduce harmful implementation dependencies to a great extent. These behavioral contracts are also a suitable mechanism to describe architectural aspects using the connector idea of Allen and Garlan [8]. Hence, we extend the object sub-typing notion by means of a behavior protocol (cf. [9]). There are several object-oriented analysis and design methods which have some notations to describe reactive behavior of an object from an external perspective, e.g. OMT [10], using statecharts [11]. Additionally, cooperative notations like sequence diagrams or collaboration diagrams are used to describe use cases, the behavior of operations, the data flow of the system and the processes of an instance. As demonstrated in [12] these notations fail because of their focus on either external state or

cooperative mechanisms to support a contract based design process. The OCoN approach can even provide a seamless integration of contracts as in detail presented in [13]. In the following we introduce our notation in section 2, present an extended example in 3, demonstrate in section 4 contract based coordination and conclude with some remarks on related and future work in section 5 and 6.

2

The Notation – OCoNs

OCoNs are a specially adjusted Petri net based formalism [14, 15]. We assume that the reader is familiar with Petri nets in general (see [16]). The elements of an OCoN are presented in figure 1. The resource and event pool elements

(a)

(b)

Figure 1: Elements of an OCoN are places in traditional nets. We distinguish between them to describe the more transient character of parameters, the control flow and temporary events by using event pools as well as the more static resource character of associations and local variables represented by resource pools. Resources are required as the carriers of activities to perform the processing of events during the computation and thus events describe the control flow of a net (see figure 1 (a) and (b)). A transition named action represents simply an operation call to an associated resource or the active instance itself. In order to avoid too complex annotations and ensure that the semantic is described visually by the net itself and not determined by the annotations, textual guards are not allowed. An action is not assumed to fire atomically, instead we assume a

action

Figure 2: Action abstraction logically atomic consume of preconditions and synchronous adding of the postconditions. The signature of an action is visualized as demonstrated by the top action in figure 2. Parameter edges are used to assign the arguments and activation edges (white arrow head) determine the object that should be activated. A simple precondition arrow stands for consuming one element of the corresponding place and a simple postcondition arrow for producing one element. Bidirectional activation edges which are only allowed for resources, represent a possibly non-exclusive modifying usage without consume character. The bidirectional parameter edge supplies a copy of the instance and is only allowed for literals or clone-able objects. For exclusive usage, a consume arrow and an additional activation edge are used. If no activation edge determines any resource for an action, the operation call is directed to the object itself. Optional pre/post-conditions can be specified in addition to the signature. A signature is visualized when implementing it with an input bar (left) and output bar (right) as shown in the service net in figure 2. The usage of a corresponding service also reflects these bars as demonstrated in the abstract visual form of an action (figure 2). Replications like parallel or sequential for-all loops are simply specified by edges with double arrows as demonstrated in figure 1(b). Sometimes external activation or sharing should be indicated. We use a shadow-like notation for shared resources and actions which are controlled externally.







ContractImpl

ContractImpl::op1

Contract1 signatures

+op1() +op2() +op3() #op4()

op1() op2() op3()

signatures

ContractR2 res2_

...

protocol net

resource allocation net [R2]

op1 [S1]

[S2]

res1_

op4

Contract2

[R1] res1_ ...

ContractImpl::op2

self

[S1]

res1_

...



op1 self

op2

[S2]

op2

... ...

res2_





ContractR1

ContractR2

...

Figure 3: Embedding with OCoNs

Figure 4: CombinedArchive example

A class described by an UML stereotype contains a resource allocation net to describe the object global coordination, synchronization, its autonomous activity and the resource dependable binding of service calls to service nets or sequential behavior specifications (see figure 3). The stereotype can use service nets to specify the behavior of external or internal services. OCoNs may be used to describe the external relevant protocol with a protocol net in a stereotype. Autonomous activity changing the external contract state is expressed in protocol nets using external actions with a shadow (see figure 6). A seamless behavior specification of all these coordination aspects is supported by the embedding of service and protocol nets into the resource allocation net and contracts abstracting from implementation details as visualized in figure 3. This aspect is studied in more detail and with the focus on visual notations in [13].

terial available digitally like statistical data. The provided services and supported archives should be embedded in a fashion that each department or company can further evolve and manage their part as wanted, but some kind of contract must be fixed which determines the requests of the overall archive system that each server has to be able to process. An additional central database redundantly storing the information should be avoided. The system should provide search and ordering for the archive. Another problem is that each institute or company provides a somehow different interface to make search requests. We simplify our view on the system and assume that the search may be specified using a condition (Cond) or a logical combination of them. We will further abstract from necessary conversions of these conditions into a suitable format for each archive server. The visual OCoN notation is used to describe the protocol of such a contract by means of a protocol net. A first simple version may require a contract that allows to search for a single condition. A protocol net can describe that the corresponding search service can be called once at a time or arbitrary in parallel. If we want to provide a search supporting the logical combinations of conditions, we have to use union and intersection on the resulting index sets. Thus for a set {C1 , C2, . . . Cn } of conditions, we have to ask n times for a selection and get corresponding selections S1 , S2, . . ., Sn . For example, for an andcombination we finally get the selection S =

3

Contracts and Protocols

For studying several possible behavioral contracts, we will use the following example of [12]. A research organization including several independent research institutes, companies and some university departments distributed over all of Europe as visualized in figure 4 wants to establish an online information retrieval system (CombinedArchive). It should combine a whole bunch of already locally installed servers for technical reports, standards and other ma-

S1 ∩ S2 ∩ . . . ∩ Sn and thus the data sent for (S1 ∪ S2 ∪ . . . ∪ Sn ) − S can afterwards be considered as some kind of unnecessary communication overhead. A solution that avoids such overhead is given when a more elaborated query service searchFormula that allows to specify a complex formula is provided. This solution avoids any complex object interaction and instead makes use of the interpreter architectural pattern [4] to separate the client and server side. Such a solution is a suitable solution as long as the provided notion for queries is able to express all needed aspects and only one serving interface is involved. When a coordinated search for a subset of all research archives should be provided, the usage of several contracts to supply the result is needed. Splitting up the request, processing the same query for every single archive and uniting the results afterwards is one straight forward solution. But when the request should already return after a certain amount of hits has been reached, this solution is still not satisfactory.

is processing the determined selection for an additional condition before it returns. So after each request we are still in the [selected] state and can access the result directly.

Figure 6: Active finite state protocol The version of figure 6 in contrast does not directly process the restriction corresponding to adding a condition. It describes the processing status using a state [active]. Thus an internal parallel processing for speed up is possible, but something like a call-back is needed to inform the client about the state change to [selected]. Our contract notation covers such call-backs by encoding them as observable state changes. This allows to integrate them into the still uni-directional contract protocol and avoids the usage of a complex bilateral or even a multi-lateral contract.

Figure 5: Reactive finite state protocol A solution is to specify a possibly complex interaction with an archive to control the search step by step to avoid this kind of overhead by observing the actual number of hits using a getNum service. Finite state machines can be used for this purpose. As demonstrated in figure 5, a net restricted to finite automaton (only consume and produce but no bidirectional edges are allowed) can be used. The version describes a protocol where each request

Figure 7: Non synchronized return service calls The restriction to finite state machines simplifies several aspects and results in the restriction that only one request per time can be processed. This is not that critical for short term operations, but leads to avoidable delays because any following request is delayed until the return arrives which may be a reasonable delay due to a slow network connection and hence

unacceptable at all. To avoid such artificial synchronization, we can simply decouple the return from the protocol automaton describing the possible call sequence for the contract (used in general in [9]). Thus an asynchronous but ensured occurrence of a return for a call is specified. In figure 7, a new version using this non-return synchronization expressed by a bidirectional arrow is shown.

Figure 8: Protocol with one way service calls A further extension is to specify add calls to occur one way which avoids any additional synchronization by omitting the useless return synchronization (figure 8 dashed boxes). This kind of contract is already optimized for concurrent processing in a distributed environment, but connection supplied via a slow network or high throughput requirements may imply such a design. There are several more elaborate solutions possible, but the discussed alternatives should give a first impression how such design decisions can be studied in the OCoN notation. The finite state protocols can also be described by statecharts, but the improved versions using implicit defined call-backs are in conflict with the assumed reactive behavior of statecharts. As demonstrated in our design considerations the capability to express synchronization and non-reactive behavior is essential. Using complex finite state spaces for contracts is of limited value at all, because the usage or even coordination of multiple ones becomes very complex. Thus, the abstraction process when building a contract protocol should lead to a reduced abstract state space that can be expressed without hierarchi-

cal state concepts. Different aspects which can be decomposed should be provided by separate independent contracts.

4

Coordination

When multiple objects share a specific contract, the assumed protocol-conformant use is difficult to ensure. Assume for example our SearchFSM contract. If such a contract is shared, the result is obviously not the assumed one because it is the arbitrary and-combination of the add requests by several objects. Thus, there are good semantical reasons to use a single contract for every request. These requests can be provided by a contract factory like SearchFSMFactory in figure 9. These contract factories should avoid any protocol and allow arbitrary request orders. They can be considered as the basic static structure used as boot strap mechanism to instantiate dynamically several behavioral contracts. In figure 9,

Figure 9: A usage of the SearchFSM contract we can also see that the partial state automaton described by the usage of the SearchFSM contract is simply a graphical embedding of the protocol net, which simplifies the usage to a great extent. Contracts and their protocols should not be developed in isolation. A design process should try to evaluate them by integrating them into use cases and behavior specifications for operations. Such an evaluation of developed contracts is important to check whether they are sufficient and their usage is practicable. This evaluation can help to avoid contract and interface changes in later phases of the design. A

first simple example how to evaluate protocols in a use case is demonstrated in figure 9.

Figure 10: SearchFormula class diagram For our combined archive example, we want to study how we can specify on a still abstract level a realization of the searchFormula operation of a SearchFormula interface. We assume that one SearchSimple and one SearchAddFactory contract is given and try to describe how to coordinate requests to them. The protocol for the SearchAdd contract is given in figure 7.

The search contract of the bookArchive can also be used to request the corresponding selections for every condition. For all conditions simply the corresponding selection is requested and afterwards the intersection for all elements of the resulting set of selections is build using a not further specified internal service intersection. Finally, both parallel processed selections should be united and the processed selection of earlier stages should be added, too. Again, a not further specified internal service (unite) is used for this purpose. Then the loop condition is tested again. It will terminate when no additional and-combined condition set is contained in the formula. The processed selection is returned afterwards.

Figure 12: searchFormula realization Figure 11: searchFormula realization The structure shown in figure 10 is reflected in the service net shown in figure 11 by the shared resource pools for bookArchive and articleArchive. We assume the formula to be given in a disjunctive normal form, so we can split it up into a number of and-combined conditions (Cond). The service net in figure 11 describes a while loop extracting one such and-combined set of conditions with the first action in each iteration. This condition set is duplicated to be used in two processing queues for the articleArchive and the bookArchive. Additionally, a SearchAdd contract is demanded for the articleArchive. Then for both archives, the processing is done in parallel. The SearchAdd contract is used by simply adding all conditions in parallel and by waiting for the result with a getList call.

A slightly modified version is needed to abort the processing when a suitable amount of hits is processed. This version presented in figure 12 is simply derived from the former version by modifying the assumed unite service in such a way that it additionally determines if already a sufficient number of hits has been found using an additional parameter limit. Then the actual processed selection is returned and the loop stops.

5

Related Work

Role based modeling in OORAM [6] provides a suitable background for the exploration of independent contracts during the design. With the OCoN approach, this aspect can also be tackled and thus their coordination and resulting conflicts can be studied in an abstract

but already instructive fashion. OORAM and CATALYSIS [17] both ignore this demand for intra-object coordination or synchronization and instead delegate the problem to the implementation level. We provide a visual formalism to apply the behavioral typing concept proposed by Nierstrasz [9]. We further extend his idea by also including spontaneous or on the return of a service depending protocol state changes.

6

Conclusion & Future Work

The visual OCoN formalism is capable of describing behavioral aspects during the objectoriented design of distributed object systems. It supports both cooperative and reactive aspects of object behavior and integrates behavioral contract specifications in a seamless fashion. Thus the correct contract usage is reduced to a graphical embedding and even complex coordination schemes can be modeled. The operational character of an OCoN allows to simulate and visualize the resulting behavior. The application of visual notations can be supported in various ways by providing well evolved tools. Thus a prototype for a net editor with integrated simulator has been implemented. Another necessary task is the integration in a case tool with sufficient support for the UML. The OCoN approach is based on the wellfounded Petri net theory, which helps to provide a well defined semantic and thus several questions of interest can be studied in this formal framework. To make such analysis available for a broader group of people, even not familiar with formal methods, more tool support is planned.

References [1] Rational Software Corporation. Unified Modelling Language 1.1, September 1997. [2] Object Management Group. The Common Object Request Broker: Architecture and Specification 2.2, February 1998.

[3] D. Chappell. Understanding ActiveX and OLE - A Guide for Developers and Managers. Microsoft Press, 1996. [4] Mary Shaw and Davis Garlan. Software Architecture: Perspectives on an emerging Discipline. Prentice Hall, 1996. [5] Bertrand Meyer. Object-Oriented Software Construction. Prentice Hall, 1997. [6] Trygve Reenskaug. Working with Objects: The OOram Software Engineering Method. Addison-Wesley/Manning, 1996. [7] R. Wirfs-Brock, B. Wilkerson, and L. Wiener. Designing Object-Oriented Software. Prentice Hall, 1990. [8] R. Allen and D. Garlan. A Formal Basis for Architectural Connections. ACM Transactions on Software Engineering and Methodology, July 1997. [9] Oscar Nierstrasz. Regular Types for Active Objects. In Object-Oriented Software Composition, pages 99–121. Prentice Hall, 1995. [10] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-Oriented Modeling and Design. Prentice Hall, 1991. [11] D. Harel. Statecharts: A Visual Formalism for complex systems. Science of Computer Programming, 3(8):231–274, 1987. [12] H. Giese. Behavior Specification for Contract based Distributed Object Systems. Techreport, University M¨ unster 05/99-I, March 1999. [13] H. Giese, J. Graf, and G. Wirtz. Seamless Visual Object-oriented Behavior Modeling for Distributed Software Systems. Techreport University M¨ unster 04/99-I, March 1999. [14] H. Giese, J. Graf, and G. Wirtz. Modeling Distributed Software Systems with Object Coordination Nets. pages 107–116, July 1998. PDSE’98, Kyoto, Japan. [15] G. Wirtz, J. Graf, and H. Giese. Ruling the Behavior of Distributed Software Components. PDPTA’97, Las Vegas, July 1997. [16] W. Brauer, W. Reisig, and G. Rozenberg [eds]. Petri Nets: Central Models (part I)/Applications (part II), LNCS 254/255. Springer Verlag, Berlin, 1987. [17] D. F. D’Souza and A. C. Wills. Objects, Components, and Frameworks with UML: The Catalysis Approach. Prentice-Hall, 1999.