DE10065286B4 - Methods for designing and / or operating combinable components (TYCS) - Google Patents

Abstract

Method for operating combinable components in application servers, in which the behavior of the components of an overall system formed from the components is described by means of interfaces between individual components on the basis of contracts,
characterized in that to describe each component
in addition to the syntactical interface description, a behavior protocol is used for each contract, which describes the properties of the component with regard to the synchronization between the components via the respective contract,
An internal dependency relation is used to describe the dependencies between offered and used contracts, which describes the dependencies within the component between offered and used contracts and together with the contracts by means of restricted contracts, which can only lead to a one-sided blocking of the contract user by the contract provider allows to exclude anomalies in the synchronization of the component with other components of the overall system,
by means of application servers and / or operating system components, synchronization anomalies of the combinable components during the operation of the components can be prevented or diagnosed by the dependency relation when combining ...

Description

The Invention relates to a method according to claims 1 and / or 2, for design and / or for the operation of combinable components according to the generic terms of claims 1 and 2.

The Design and operation of software programs that are usually quite extensive is characterized by a variety of problems in practice. One problem is that extensive Software programs from a large number are developed by employees in parallel and therefore for implementation different sub-functions frequently each have their own program routines developed. The resulting frequently monolithic structure of many extensive application programs requires that at Applications often in identical or similar Form recurring sub-functions are often specifically new have to be implemented whereby the programming effort and the length of the program code and thus the costs for software development increases significantly.

A frequently required design rule for Software projects is therefore the level of reuse of the Increase software modules. So far, frameworks or libraries have been used in practice. known to be the usual Represent the form of reuse of software elements. In such Libraries or frameworks are always needed software fragments filed and documented which data must be transferred and what values are returned become. Appropriate explanations of the internal functioning should also be provided the libraries or frameworks or their components.

Furthermore are different component systems [Szyperski 1998] and corresponding infrastructures in the form of operating system extensions or so-called application servers introduced and been standardized. A number of approaches are limited to the aspects of graphical user interfaces (OLE + COM, JavaBeans) while for the whole Application design COM + with MTS, Enterprise JavaBeans with JTS and to name the CORBA components that are in the process of standardization are. One hopes that these innovations will make productivity decisive to be able to increase and the problems described as the "software crisis" overcome software development at least partially to be able to.

All such approaches have the disadvantage, however, that behavior when exchanging individual program components for others of the entire program system need not necessarily be stable. Becomes for example, in the simplest case, a subroutine from a program library exchanged for another that is delivered Results should be functionally the same, for example if callbacks (i.e. calls that return range) possible are still not guaranteed, that this new subroutine does not affect the software process. For example, through the internal functioning of the subroutine cause such conditions that this Subroutine no more meaningful or no values at all the calling program back delivers and so this calling program does not continue to work can or no longer works sensibly. This can, for example the overall function of the software are questioned, whereby especially in technical control processes e.g. for manufacturing plants or the like. Real-time dependent Applications of this "hanging" of the software are serious can have technical and financial implications.

can with conventional Approach to software development of this software getting stuck be avoided that as many as possible conceivable states e.g. are tested in subroutine calls and thus within the Precautions corresponding to the subroutine or the calling program can be taken to intercept such undefined states, so is increasing with the modularization of software and the trend while Such a procedure during the runtime of newly configured software due to the variety of possible combinations the software components no longer make sense or no longer reliable enough.

In this context, a component is an element of the overall system with well-defined contracts that are offered and used and that can be used independently. A contract is a well-defined interface that can include syntax, functional behavior (preconditions and postconditions), synchronization (protocols) and quality of service. A service (English service) is a service offered via one or more well-defined contracts; service mediation (English trader) means the infrastructure for dynamic allocation of services. The use of components is intended to make it easier to achieve modular rather than monolithic systems, which enables an increase in the degree of reuse and interchangeability of components at runtime of the program. By using contracts By later assigning the services, increased flexibility and expandability of the software is made possible.

The in itself ideal design and operation of software components in a completely modular Wise is due to limited contract terms used in practice and the one listed above Problem of testing software elements one in the past Practice not yet achieved. The previously used Processes and technologies for Instead, software components are syntactic in scope Contracts limited, whereby the synchronization of the components alone is not secure guaranteed can be.

The Middleware products available today support one interoperability only in the form of an appropriate coding of messages and the standardized handling of remote calls. That's why it's enough the interface terms supported by the runtime systems usually not out to match between expected and accomplished behavior of the software components sure. The application of complex mathematical models, about functional conformity guarantee of component connections, e.g. the design with pre and post conditions (design by contract [Meyer 1997]) possible, but not yet common in practice. By Use of interface inheritance or unique identification numbers however, each interface can, at least theoretically, have a complete interface specification be assigned. However, this forces that for the cooperation of two program components necessary interface is completely standardized. Services and their mediation between components is therefore either a priori limited to basic contracts or the service assignment is running Danger, wrongly a "fit" of the components to determine because match for functional Behavior in general cannot be determined efficiently.

in the Contrast to individual contracts between two components and their syntactic and functional components can be found in the Synchronization in a complex software system not be limited to individual connections between individual components, but rather must in general all conceivable connections between all components for the entire system. This non-locality ("transitivity") of the effects and dependencies leads to, that a Analysis of synchronization effects the whole when combining emerging system must include. In general, the consideration of both the offered such as the behavior specification comprising the contracts used necessary. In this context, behavioral specification means that the possible Interaction of the component with its environment via the contracts provided by the contracts Calls or the like is completely described.

The resulting possible Variants for compatible Component behavior that other components replace in any context can do so without endangering the entire system Very limited behavior. That's why it's modular of the system generally not based on this specification is given instead, a corresponding one is given when the component is replaced complex analysis of the system necessary. This is even for the simple one Class of finite automata with parallel combination of components the exponential growth of the state space (“state explosion problem ") to observe, which suggests that such an analysis is generally not efficient for arbitrarily combined systems possible is. A general exchange should also be more useful if adhered to Restrictions possible be otherwise the modular further development of components supports is.

In practice, due to the enormous complexity and the resulting very restrictive restrictions for valid replacements (English refinements), no complete behavioral specifications are considered. Component systems are therefore now characterized in that either a generally restricted architecture is required to rule out possible synchronization anomalies, or the problem is ignored entirely. The dependencies between the offered and expected contracts of a component can make explicit observation unnecessary in a strictly hierarchical design (English: "layered architecture"). In general, one describes the generic patterns according to which the components can or should cooperate. An example of this would be one So-called "pipe and filter" architecture, the elements of which can each process a stream of data. In contrast to the interface descriptions, which are usually limited to syntactic aspects, the description and description of software architectures also pay attention to the behavior and interaction of the parts. As an example, only the explicit "connector" term from [Allen & Garlan 1997] should be mentioned, which uses protocols to describe the possible interaction sequences for connections. If no suitable comprehensive software architecture [Shaw & Garlan 1996] is defined, the integration of components itself can be done fail when using adapters ("architectural mismatches"). In the case of not strictly hierarchical or mixed and overlapping architectural styles, the expectations and assurances regarding one Component increasingly unclear. A systematic and practicable way of describing this for a component is missing these days.

The potential Synchronization anomalies when using component-based software can have their cause in semantic assumptions and effects that too partially cannot be excluded using database technologies can. About that can out distributed, longer in time Transactions and detection of deadlocks in distributed Systems are not scaled arbitrarily and therefore in practice lead to not inconsiderable performance problems. Today's component approaches are limited to the necessary database concepts, such as transactions and persistence, to integrate through standardized interfaces. The problem addressed here the result of interactions that do not harmonize with each other Synchronization anomalies are therefore largely independent of database technologies to see.

As an example to illustrate the possible problems that arise from the synchronization of components, the example of a flat directory service [from Syperski 1998, p. 52) can be used. The scope of the component is the in 5 (left) given interface (contract), which describes how the directory can be modified accordingly using the operations lookup, add, remove, register and unregister. The operations are specified with appropriate preconditions and postconditions (cf. [Meyer 1997]) by curly brackets, where {query} describes that an operation has no side effect on the state of the component, lookup 'in a postcondition the previous result of describes lookup before performing the operation and (pred? a: b) for pred pred pred true a otherwise b.

For the example is described in [Szyperski 1998] as due to registered Observers and the callbacks that occur to them an implementation lead to a stack overflow can. If an observer only acts locally when the callback occurs, e.g. by updating the current display, that's how it works smoothly. On the other hand, if the observer wants to Entries with a prevent certain names by deleting them directly, so can result in an infinite size and thus the stack overflow come. These problems can cannot be avoided without specifying a specific implementation.

In order to better understand the phenomenon occurring in the example and its handling, we should briefly refer to callbacks and the related Effects (cf. 5 (right)).

are two components through a normal contract and a contract in the opposite direction for connected a callback, there is basically the problem that cyclical Calls are not excluded. These can be in the simple, non-concurrent case e.g. lead to the described endless regress and stack overflow or generally for non-termination or unwanted synchronization effects.

Another possible approach to illustrate synchronization dependencies is to differentiate between "exclusive" and "shared" contracts. In 6 is an exclusive variant of the directory service without callbacks, which is described in 5 the complete pre and post conditions specified. The "shared" version 7 on the other hand, because of the different accessing contract users, none of the contract users can guarantee such preconditions and postconditions, since the competing access of the different contract users does not guarantee that inserted entries are retained.

Callbacks generally lead to a high degree of coupling and therefore it is a good strategy to exclude such effects as far as possible, instead of using callbacks only events for coupling. Such a solution is in 8th described. The "shared" contract SharedDir is expanded accordingly by the events added and removed. This solution excludes the direct infinite regress and thus stack overflow by the fact that the event processing takes place asynchronously and is therefore processed independently of the control flow modifying the directory.

In cases where such asynchronous processing is not sufficient, the use of callbacks cannot be avoided. In 9 (left) a corresponding solution is presented. From 5 already known register and unregister operations must be added. However, this brings us back to the original problem and for any implementation, neither a stack overflow nor other synchronization problems can be excluded. A corresponding constellation is in 9 (right) shown. In the case of possible cyclical calls, the phenomena mentioned can occur.

If the functionality described in the original example is now to be achieved, this can only be done with the above scheme while maintaining the cyclic call graph if the incorrect entries are deleted asynchronously. Ie the above component 9 calls remove for the NotifyingDir contract and the corresponding entry only after the callback has already been completely processed. In this case, as in the obi event-based solution also excluded the observed problems. With regard to the original solution, it should be noted here that only an asynchronous solution would be secure and that even immediate access to the NotifyingDir interface does not guarantee the necessary consistency in the concurrent case. On the contrary, the question arises of how a corresponding implementation treats a change regarding other requests as long as the callbacks have not yet been scheduled. If the described form of asynchronous remove is not sufficient with regard to the desired consistency, the problem must be addressed differently. In 10 a corresponding extension is presented. In addition to a general notify contract that only allows asynchronous access (see above), so-called guards are supported, which allow all registered guards to be asked whether an entry is compliant before an entry is inserted. This means that the solution prevents a corresponding entry from being made at all.

If one considers not only the simple flat directory service but also those that contain other entries in addition to concrete entries (files), then depending on the occurrence of multiple references in the general cycles in the structure are not excluded. For this reason, the systematic search in such directory trees with links also leads to the problem that repeated searches with multiple contents or cycles must be avoided or excluded. This means, for example, that the CORBA Name Service only offers traversal and not recursive searches. In 11 corresponding structures with arbitrarily linked contracts are shown. In the left case, the component offers an ExtDirectory contract, which not only supports, for example, traversal, but also recursive search. If an operation that searches the entire structure recursively is to be offered, this can also be done, as in 11 (right) can be offered through an additional contract. Both constructions are correct as long as the recursive search cannot lead to cyclic call chains. However, this is not impossible for the given components.

task The present invention is a generic method to design and / or to operate combinable components like this further elaborate that synchronization anomalies and the like effects can be safely excluded and thereby the reusability and interchangeability of the components to increase significantly.

The Task is solved by the method according to claims 1 and / or 2. Further advantageous refinements of the invention result from the subclaims.

The The basic idea of the present invention is types for components (Typed Components Systems, TYCS for short) to use the synchronization behavior of the components when composing into an overall system and thereby avoid the problems mentioned above.

Becomes a contract in a defined definition space for all components globally defined in this definition space, is known to all components equally, so in the context of this invention, this contract is called the basic contract designated. Corresponding are here under a multi-contract Descriptions of the behavior of a set of individual contracts understood that about the behavior defined in the individual contracts further restrictions include. A so-called combined contract describes a contract that in a local definition space from basic contracts of a global Definition space can be defined and based on its support the global definition space a use in the global definition space allows without having to be defined globally.

In order to will it be possible locally to specify extensions of the overall system, which too of components that only have the defined global definition space know, can be used locally.

The The invention is based on a design method and / or for the operation of combinable components in which the behavior of the Components of an overall system formed from the components by means of Interfaces between individual components based on contracts is described. This generic method is further developed by that for Description of each component in addition to the syntactical interface description a protocol of behavior is used for each contract the properties of the component with regard to synchronization via the describes each contract, and an internal dependency relation The dependencies within the component are used by means of contracts describes and together between offered and used contracts with the contracts allowed, anomalies in the synchronization of the Exclude component with other components of the overall system. The Contracts are limited to the extent that they only block unilaterally allow the contract user by the contract provider.

Thereby, that for Description of each component in addition to the usual syntactic interface term a behavior log for every contract available stands, it is possible the synchronization over to describe the contracts. The dependency relation regarding offered and used contracts defines to what extent offered behavior may depend on the behavior used in the sense of synchronization. So the combination of components is always possible as long as the resulting one dependency relation does not contain cycles that an impermissible self-referentiality include. It is unnecessary Therefore, the exact functioning of the component is new to have to examine should the component be used again in a different context or by another functionally identical or functionally similar be replaced. It is enough to ensure synchronization which symbolizes the internal behavior of the component Description from dependency relation and behavior log to look at to make confident statements about that Occurrence of cycles due to an impermissible self-reference or other synchronization anomalies. Therefore is the reusability of the component or its replacement by other components are much easier to do than according to the status of technology otherwise possible today would.

To are the behavior logs on calls, asynchronous calls or events generated by the contract provider. The Contract users are committed to the results of a call or accept events immediately so that the contract provider does not can be blocked. Instead of so-called "guarded operations", which are used in programming Concurrent Systems often The contract user is synchronized via externally visible states, so that possible blocking conditions are public must be known. Strictly speaking, even simple syntactic interfaces with remote calls implicitly a protocol with guaranteed behavior - namely that a response is returned to a request - describe these interfaces also provide a kind of behavior log or something very similar to disposal. Thus, it is not always necessary to keep a log of contracts to define explicitly, but instead can also be implicit Definition. Taking behavior log in this The meaning should be either an implicit or an explicit one Behavioral log can be understood.

In In this context, the concept of the component is intended specifically in the way generally characterize the property that development and application independently can be done from each other. Here, a component can be used both in terms of hardware and software can also be mixed, as is particularly the case with heterogeneous ones Computer systems often the case is.

Herewith it is therefore also possible to decide whether a given typed component (TYCS component) due to their external specified properties in a given Architecture of an overall system can be inserted.

Farther it is conceivable that by means of the behavior protocols an efficient test for connectivity for out Basic contracts combined contracts is carried out by the states of the Combined contract described as a combination of the basic contract conditions become. The connectivity between two contracts A and B ensures doing that, if A is offered by one component and B by another Component is needed contract A coupled to the second component contract B fulfill can. Couplable from A to B does not immediately follow that B also must be connectable to A. By one if possible The flexible composition enables the contracts to be fully coupled of components based on contract connections.

In addition to the individual contracts and the dependency relation that implicitly describes the dependencies, there may also be explicitly known restrictions regarding the combined behavior of a set of offered and used contracts. This explicit synchronization (so-called complex contracts) can be used, for example, to make buffering effects externally visible where necessary. You can do this for a set of contracts offered and used for a component (see in 2 and 3 the dashed boxes) specify a behavioral restriction.

• – Falls das durch einen Kontrakt angebotene Verhalten von einem benutzten Kontrakt abhängt, so muß dieses durch die Abhängigkeitsrelation abgedeckt werden. Wenn z.B. die Beantwortung eines Aufrufs an einen angebotenen Kontrakt durch eine Komponente neben lokalen Berechnungen auch des Aufrufs eines benutzten Kontraktes bedarf, so müssen benutzter und angebotener Kontrakt in interner Abhängigkeit zueinander stehen. Kann etwa durch Pufterungseffekte oder dgl. innerhalb einer Komponente das zugesicherte Verhalten eines angebotenen Kontraktes von dem Verhalten eines benutzten Kontraktes abhängig sein, so muß die Abhängigkeitsrelation ebenfalls erfüllt sein.
• – Eine Komponente darf das Bedienen von angebotenen Kontrakten nur insoweit von Anfragen oder Verhalten benutzter Kontrakte abhängig machen, als diese Benutzung bei Annahme des garantierten Verhaltens für die benutzten Kontrakte zugesichert ist. Im einfachsten Fall kann somit eine angebotene Prozedur nur wiederum eine durch einen benutzten Kontrakt bereitgestellte Prozedur nutzen, wenn deren Terminierung auch tatsächlich garantiert ist. Im allgemeinen Fall bedeutet dies, daß das zugesicherte Verhalten eines angebotenen Kontrakts und seines Protokolls nur wiederum von zugesicherten Eigenschaften eines benutzten Kontraktes und seines Protokolls abhängen darf. Wenn etwa ein benutzter Kontrakt zum Beispiel ein willkürliches Ereignis beinhaltet, so darf das zugesicherte Verhalten eines angebotenen Kontraktes auf keinen Fall von dem Auftreten dieses Ereignisses abhängig gemacht werden.
• – Das Verhalten einer Komponente muß dem in dem zugehörigen Multikontrakten beschriebenen Verhalten entsprechen. Ist z.B. in einem Multikontrakt für einen angebotenen und benutzten Kontrakt beschrieben, daß bei Einfügen eines Elementes über den angebotenen Kontrakt ein entsprechendes Element an den benutzten Kontrakt weitergereicht wird, so muß die Komponente dies entsprechend auch tatsächlich gewährleisten. Der Multikontrakt beschreibt dabei maximal, inwieweit Protokolle der Kontrakte in ihrem Einzelverhalten einander beeinflussen und kann somit auch dazu verwendet werden, zu beschreiben, wie mehrere angebotene Kontrakte einander beeinflussen.
• – Die angebotenen Kontrakte müssen sowohl untereinander als auch für parallel erfolgende Anfragen fair durch die Komponente gewährleistet werden, soweit dies nicht durch einen Multikontrakt explizit eingeschränkt wurde. Wenn etwa zwei angebotene Kontrakte nicht durch einen Multikontrakt weiter beschrieben sind, so muß die Komponente deren Verhalten dem Protokoll entsprechend für beide parallel und fair anbieten. Ist dagegen das Verhalten der beiden Kontrakte durch einen Multikontrakt beschrieben, so muß die Komponente nur das in dem Multikontrakt beschriebene eingeschränkte parallele Verhalten gewährleisten.

A set of appropriately chosen rules of conduct limits all permitted component behavior for a given set of contracts offered and used and their dependency:

• - If the behavior offered by a contract depends on a contract used, this must be covered by the dependency relation. If, for example, the answering of a call to an offered contract by a component requires the call of a used contract in addition to local calculations, the used and offered contract must be internally dependent on one another. Can, for example, through buffering effects or the like. Within a component, the guaranteed behavior of a contract offered depends on the behavior of a contract used the dependency relation must also be fulfilled.
• - A component may only make the operation of offered contracts dependent on requests or behavior of contracts used, insofar as this use is guaranteed when the guaranteed behavior is accepted for the contracts used. In the simplest case, a procedure offered can in turn only use a procedure provided by a contract used if its termination is actually guaranteed. In general, this means that the guaranteed behavior of an offered contract and its protocol can in turn only depend on the guaranteed properties of a contract and its protocol used. If, for example, a contract used contains an arbitrary event, the guaranteed behavior of a contract offered must under no circumstances be made dependent on the occurrence of this event.
• - The behavior of a component must correspond to the behavior described in the associated multi-contracts. If, for example, a multi-contract for an offered and used contract describes that when an element is inserted via the offered contract, a corresponding element is passed on to the used contract, then the component must actually guarantee this accordingly. The multi-contract describes the extent to which the protocols of the contracts influence each other in their individual behavior and can therefore also be used to describe how several offered contracts influence each other.
• - The offered contracts must be guaranteed fairly by the component, both among themselves and for parallel requests, unless this was explicitly limited by a multi-contract. If, for example, two offered contracts are not further described by a multi-contract, the component must offer their behavior in accordance with the protocol for both in parallel and fairly. If, on the other hand, the behavior of the two contracts is described by a multi-contract, the component only has to guarantee the restricted parallel behavior described in the multi-contract.

By Combinations of any or all of these restrictions can be achieved that the Contracts together with the internal dependency relation an adequate Description of the components for the later Represent composition. In contrast to those from the prior art known complete external NEN behavioral specifications considered only implicitly and this approach allows the question of whether one component can safely replace another, directly based on of the individual contracts and the internal dependency relation. This context-independent Interchangeability is very flexible because of the implicit description gets a lot of freedom about that furthermore, it is based on the simple criterion of freedom from cycles also possible, Carry out replacements, that are only possible in the given context.

Likewise can in a further embodiment the dependency relation in composition of components for the resulting new component by linking the individual dependency relations the components and abstraction of the basic contracts.

The free combinability of the components can only be restricted to the extent that the combined dependency relation created by the combination must be without cycles (see 1 ). Then the occurrence of permanent blockages by synchronization between the components can be excluded. On the one hand, this enables the property to be tested efficiently and, moreover, also provides an easy-to-understand metaphor even during the combination of components.

Become Components only combined using simple contracts, so the condition is that Combined behavior is free of deadlocks, with more cycle-free combined dependency relation given by construction.

• – Das aus der Kombination der Menge von Multikontrakten und der beteiligten nicht weiter durch Multikontrakte eingeschränkten Kontrakte resultierende Verhalten muß frei von Verklemmungen sein und unendliche interne Aktivität, die eine Bearbeitung externer Anfragen verhindert, muß ausgeschlossen sein. Diese Betrachtung macht im allgemeinen dabei nur Sinn, wenn alle beteiligten Kontrakte verbunden sind.

For an overlapping set of multi-contracts, when combined to rule out synchronization anomalies, the following condition must be met:

• - The behavior resulting from the combination of the number of multi-contracts and the contracts not further restricted by multi-contracts must be free of deadlocks and infinite internal activity that prevents processing of external inquiries must be excluded. This consideration generally only makes sense if all the contracts involved are linked.

Then can for the resulting combination synchronization anomalies can be excluded.

In addition to the unique combination in operation, it makes sense to combine the appropriate combination of sub-components into a predefined component that is formed by the composition. The composition causes a combination in which the internal con tract connections are visible, is abstracted to a corresponding component that only reveals the unconnected contracts.

In the simple case that there are no multi-contracts, one can simply abstract syntactically from the internal structure and the internal connections (see 4 ).

For complex Contracts must be next the anomaly-free combination is the amount of linked multi-contracts either entirely within the combination or entirely outside lie, i.e. that for no one offered or used multi-contracts is the connection of further Components possible.

Then the resulting component can be abstracted from the internal behavior described by the combination of the complex contracts and a much simplified type can be concluded (see 3 ).

In the event that an overlapping set of multi-contracts has both internal and external components, the behavior of internal contracts can also be abstracted. To do this, the more abstract behavior must be a refinement of the behavior resulting from the combination (see 2 ).

A Another embodiment of the invention relates to the composition of Contracts.

The Interface term used in practice is limited on syntactical aspects and does not describe that of a contract underlying synchronization. Extensions proposed in the literature range from simple protocols to completely mathematically specified ones Contracts. The consideration of behavior in conformity with the contract generally leads to a high complexity.

Furthermore can generally finite automata are treated efficiently.

Around now both the complexity to reduce as well as the assignment of further semantics e.g. Support in the form of pre- and post-conditions are in addition to the pure Sequence of calls and their restrictions (non uniform service availability) assigned declared states to this behavior. So can the entire semantics specified in relation to the abstract protocol become. This construction also allows the formation of new types by combining given and adding new components, taking on the full semantics of the combined parts by using of states and operations are referenced. The basic concept, however expanded by the consideration of behavioral protocols, corresponds to the "compound types" [Buchi & Weck 1998], which addresses the problem independently developing Subsystems and the resulting lack of compliant type hierarchies prevent. Through this use of basic contract aspects, a efficient test for contract compliance can be achieved, with a conformity based on the synchronization a comparison of the states and their assignment to each other can be done.

Around to achieve a more flexible and secure expandability for contracts, on the user page at runtime you can adhere to the Force protocol. Another option is to go further the explicit states as condition preconditions at runtime in addition to the messages if necessary to use to encode the calls so that in more make achieves a contract conformity can be. Where appropriate, the contract protocols are included Adjusted information at runtime by sending the data, to minimize the additional effort.

This provides a corresponding order on the contracts, the one Safe use of a contract regarding synchronization anomalies for all his extended types (subtypes) guaranteed if one of the effects, that result from the coupling of several contracts of a component and that is covered by the component notation.

In practice, suitable contracts (services) are usually identified at the time of drafting. Further approaches for distributed systems try to identify a suitable contract contract for a contract user at runtime by a service agent either by means of global type systems, based on syntactic information (structural subtyping), or by means of additional information, which is generally not further specified. For such a procedure, the efficient contract conformity test, which includes the protocol behavior, can be used for the developed contract notation. The dynamic assignment of contracts does not have to be limited to a global type system, but only to any combination thereof, because for contracts that are only formed by a combination of basic contracts, each contract type that is formed independently of one another and that has the same initial contracts can be created using the common basic contract aspects Basic contracts implemented and a compliant protocol supported, recognized as compliant and thus possible contract provider. If contracts themselves appear as parameters, they can be referred to recursive type definitions return and treat using "structural subtyping".

The described component and contract notations allowed in the presented the design of jam-free systems. This can be done at design time using the techniques described the system formed from existing or planned components based on the vivid and compact external component specification regarding possible Problems are investigated. The external component description defines in the form of the contracts which contract links in the final System are correct. The dependency relation as well as complete areas overlaid by complex contracts it for the resulting composition to rule out synchronization anomalies.

The inventive method allows es, systems and subsystems taking synchronization into account to attain through composition. The properties described lead here to a runtime behavior that excludes synchronization anomalies that difficult or impossible to rule out by tests.

The developments described can both while of the design as well as in operation. Your integration into an operating system, application server or configuration tools Last but not least, the composition is only allowed by the administrator or even end users in a flexible way to let.

By the described combined contract notation can be used in operating systems or application servers a higher one flexibility can be achieved when assigning contracts (services). necessary Restrictions can be monitored and the maintenance and modification of the system can be done at runtime be diagnosed. The contract and component terms described allow about it free exchange of components and their integration into other systems based on the concept of a contract.

The The invention further relates to a method according to claim 19 for design and / or for the operation of combinable components in which the behavior of the Components of an overall system formed from the components by means of Interfaces between individual components based on contracts is described. Such a generic method is thereby further developed that the Coupling of contracts at runtime of the overall system only then is allowed and / or brokered when combined from base contracts Contracts where the states of the combined contract is described as a combination of the basic contract conditions be regarding an efficient test of connectivity successfully carried out becomes.

hereby can be achieved that in general for the Combination of components over Contracts at runtime problems in the contract specification be covered by synchronization, functional behavior or the quality of service do not occur when using a dynamically linked contract can, because the composition of contracts from basic contracts allows Couplability regarding of the listed Guarantee aspects. The solution also allows the ability to link contracts to be determined without that these in a common domain or in a specific one Order have been declared. This enables separately developed components if necessary, use mutual contracts without them were defined in a common definition environment. Instead it is enough if these combined contracts are on a lot obtain from basic contracts of the common definition environment, to decide when an offered contract will need a contract can operate. Otherwise you can also essential aspects of the invention according to claim 1 and the the above explanations relating to this also apply to the solution.

A particularly preferred embodiment of the method according to the invention according to claim 1 shows the drawing.

It demonstrate:

1 - restrictions on the composition of software components,

2 - abstraction in the composition of multi-contracts,

3 - abstraction when composing with a closed set of multi-contracts,

4 - abstraction in the composition of components,

5 - Directory service with callback ([Szyperski 1998, p. 52]),

6 - Directory service with "exclusive" access,

7 - Directory service with "shared" access,

8th - Directory service with observable events,

9 - Directory service with notification of changes,

10 - Directory service with notification of guards when changes occur,

11 - recursive directory services with search function,

9a - Directory service with notification of changes according to 9 but using the TYCS concept,

10a - Directory service with notification of guards when changes occur 10 but using the TYCS concept,

11a - Recursive directory service with search function according to 11 but using the TYCS concept,

12 - Task, unit and AFT offer component schemes as an example for an application on a flexible manufacturing system,

13 - Scan component and jam-free combination on a flexible manufacturing system,

14 - Scanlmpl component in combination with ScanUnit2 on a flexible manufacturing system,

15 - Scanlmpl2 component and combination with ScanUnit2 on a flexible manufacturing system,

16 - Scanlmpl2 component and combination with cycle on a flexible manufacturing system,

17 - composition of processes to a combined process on a flexible manufacturing system,

18 - Copy sequence as a composition of two partial sequences on a flexible manufacturing system,

19 - Copy process with modified component in the subordinate process on a flexible manufacturing system,

20 - Dependency-reducing modifications to a flexible manufacturing system,

21 - composition failure due to additional dependencies in a flexible manufacturing system,

22 - Basic contracts for book orders and address details,

23 - basic contracts for payment and delivery,

24 - Combined contract for a bookshop,

25 - composition of contracts for a BookOnDemand device,

26 - Maximum composition of basic contracts of the online bookshop,

27 - composition of the basic contracts of the online bookshop, which is satisfied with any payment method,

28 - Scenario of suitable contract connections in the online bookshop.

in the the figures are used to describe where possible the unified modeling Language (UML) [UML1.3] is used. Components are added to the UML both as types and as instances in UML class or instance diagrams used. Simple circles describe exclusive contracts (not as partly in the UML only interfaces) and circles with double edges describe "shared" contracts between can be shared among multiple users. One describes simple edge between a component and a contract that this Contract in the designated multiplicity is offered while a Arrow indicates the use accordingly.

The in the example for the combined contracts according to 22 to 28 The notation used for the protocols represents a Petri net variant in which the possible states are coded by the hexagonal digits, of which only one can always be assigned. The transitions denote different forms of calls and non-deterministic behavior. The simple named transitions describe the possible calls including possible alternative returns as well as their influence on the contract status. In contrast, the transitions shaded indicate non-deterministic state transitions.

In the 9a . 10a and 11a is gradually treating in the 9 to 11 Systems already explained above, but now described using TYCS software components to show how the problems and implicit dependencies described with regard to the systems are avoided that without specifying a specific implementation.

Describe for the system 9 (right) as in 9a If the TYCS dependency relation (dotted line) is shown, such a fatal cyclical effect can be excluded, for example, in the upper case, since the component that is used guarantees that in the event of a notification, the Notifying-Dir contract will not access the contract directly (no dependency shown). On the other hand, in the lower case, due to the dependency between the Notify contract and the Notifying-Dir contract, this already described problem can arise with regard to the callback. For those in 9a Realization of the NotifyingDir contract described has only been stipulated that the contract is dependent on the Notify contracts. Thus, with regard to the TYCS dependency relation, only the upper left component is correctly connected to it, while the lower left component leads to an illegal dependency. This clearly illustrates that the composition of the dependency relation and the exclusion of cycles effectively exclude the possible problem.

Should the in the original example in 10 described functionality can be achieved and is the in 9a The form of asynchronous remove described is not sufficient with regard to the desired consistency, so the problem as in 10a to be discribed. In addition to a general notify contract that only allows asynchronous access (see above), so-called guards are supported, which allow all registered guards to be asked whether an entry is compliant before an entry is inserted. This means that the solution prevents a corresponding entry from being made at all. In order to allow a correct connection to the component offering GuardedDir, the guards must operate the Guard contract independently of the GuardedDir.

Concerning. of the recursively defined directory component structures 11 the corresponding problems can also be excluded using the TYCS dependency relation (see 11a ). The solution on the left regarding the component-internal dependency relation is not suitable for the general case, since the general composition can lead to cycles. Rather, the correct composition excludes cycles and you are therefore only able to form acyclic graphs. If an operation that searches the entire structure recursively is to be offered, this should be done as in 11a (right) described by an additional contract. Since the DeepSearch contract only depends on another directory and not in turn on other DeepSearch, the resulting dependency relation is always acyclic and corresponding problems are excluded. A corresponding implementation could only be based on other directory contracts, but not on the DeepSearch contract due to the given dependency relation, and would therefore carry out the necessary traversing locally as required with the detection of cycles.

If one next to contracts without a protocol, all of their operations always offer, including those contracts, their offered operations and condition vary (non uniform service availability), including, so must generalized the above considerations to behavior logs become. contains e.g. A contract guarantees that in response to a request An event follows in the foreseeable future, so it can also take place without an active one Calls for comparable effects come. The TYCS software components and include their dependency relation therefore more than just an approximation of the maximum call graph and the integrated protocols and corresponding dependencies.

Another example of the use of the TYCS components is given in the 12 to 21 considered a manufacturing for a distributed flexible industrial production. The workshop-oriented production system should allow flexible and expandable production of prototypes and individual pieces on the basis of autonomous driverless transport systems (AFT) and partly autonomous production machines.

As Basic configuration is a manufacturing environment for mechanical mill given plastic parts that several machine tools (e.g. Five-axis CNC milling machines) includes. There is also a 3D scanner for capturing shapes Is able to create CAD models from given templates.

Further the production system consists of an automatic high-bay warehouse, in which the workpieces and blanks and to which the finished workpieces are also handed over.

The main focus for the system control is to enable the complex manufacturing and acquisition processes that are sometimes necessary in a suitable modular and adaptive form in a service-based infrastructure. The individual processes (tasks) should include the removal from the automatic high-bay warehouse, the processing or recording through the necessary processing steps, and finally the supply to the exit interim storage facility. The incoming warehouse, the processing and recording machines and the AFTs have individual controls and are able to use a wireless communication system exchange information and messages with each other in order to coordinate the transfer of the workpiece. The AFTs also offer individual transport services as part of the service infrastructure.

The processes initiated externally can essentially only combine the basic functionality provided by the relatively autonomously operating machines and in the form of services:
For a process (task) is within the framework of the overall architecture, as in 12 (left), provided that, in order to guarantee the necessary conformity of the combined processes in the case of trader-based new combinations, the following scheme is followed. In order to be able to handle exceptional cases appropriately, a higher-level task of the lower-level task must offer a corresponding policies interface, to which the latter must turn when appropriate exceptions occur. Furthermore, it is stipulated that a process in its guaranteed behavior may only depend on the guaranteed behavior of the sub-processes and the higher-level policies. The policies also offered must be processed in parallel with task requests and may only depend on the higher-level policies. The config contract used for general diagnosis and system monitoring may only report the current local status and may not be based on one of the contracts used.

The services provided by the machines (unit) are to be used as basic processes, these are in 12 (Middle) specified. The guaranteed behavior of these can depend both on the policies contract and the corresponding loading via the load contract. The unload contract, which is also provided, may only depend on the load and the internal processes of the machine.

The driverless transport systems accordingly offer the Move service and thereby guarantee that the behavior guaranteed there only depends on the correct offering of the unload contract used (see 12 right). With a move, a workpiece is moved from one location (machine, warehouse) to another.

With the help of this basic architecture and its specific roles, the 13 As a further example, the scan process is described, which is essentially based on a 3D scan service that is offered by a ScanUnit and allows a 3D model of a template to be obtained in the form of a CAD model. Furthermore, two Move services together with the functionality provided by the warehouse (In / Out) are used to bring any workpiece from the warehouse to the scanner, to record it there and finally to return it to the warehouse. The corresponding composition can be found in the instance diagram in 13 to be viewed as. The cycle-free dependency relation guarantees that the synchronization between the components cannot lead to blocking if all subcomponents operate correctly. Concerning. internal failure, for example an AFT failure, naturally does not apply.

Are with a ScanUnit2 component in the 14 that are alternative to ScanUnit 13 can be used, all exceptions to be reported for the policies contract, regardless of the 3D scan contract, the component type can be reduced accordingly by the dependency (see 14 ). This component would then also be able to work correctly with the Scanlmpl2 process, which directly accesses the 3D scan contract for some policies notifications, because in ScanUnit2 these are in turn independent of requests to the policies contract. This manifests itself in the cycle-free composition, as in 15 shown. However, if you try to connect Scanlmpl2 to the original ScanUnit, it will work as in 16 clarifies a possible problem. If the ScanUnit would ask the policies contract for a decision due to an exception, but, in order to guarantee the internal consistency, the further processing of 3D scan requests would be suspended, and if ScanImpl2 actually received the policies request via the 3D scan interface, so both systems have blocked.

Using an expanded composite process, which combines the scan process with a second DoCNC process, it should be considered how the changes occurring over time and the encapsulation aimed at by the components interact. The in 18 Used DoCNC contract provider CNC-Impl realizes this order essentially by using a 3D-CNC contract, which allows milling according to a given CNC program, and by means of a quality contract, to check the results of the milling. If, within the framework of the DoCNC contract, the workpiece is returned to the warehouse, depending on the outcome of the inspection, the workpiece may be considered a committee. In order to calculate the suitable CNC program based on the CAD model provided by the scan process, the Copylmpl component uses further CAD and CNC libraries together with the corresponding tools.

The composition of the copy process and its subordinate processes is as in the 17 described, equivalent to a slightly modified procedure in terms of possible component synchronization.

If it now happens that, for example, according to 19 If a new CNC milling machine with the 3D-CNC + interface and built-in quality control is installed in the system, it makes sense to integrate it appropriately. If the new machine can be coupled instead of the old machine, it can first be used as a replacement.

This alone would but it does not yet allow the additional appropriately Skills of the 3D-CNC + contract. To do this you would have to If necessary, all control programs without a flexible process layer customize that a CNC milling machine to use. The flexible drainage layer, on the other hand, is enough subordinate processes to modify that access directly. In our case results this in the new subordinate process CNC-Impl2, which controls the quality in the milling machine uses itself and thus saves transport. Considered one the new skills not even with existing processes, only newly added control processes can use the new machine appropriately.

The real advantages of the service-based basic architecture come into play when either the new or the old machine is removed. For both machines the processes are still there, the dynamic service switching can ensure that the system continues to work unimpeded. Due to the service-based overall structure, when a copyltem service is instantiated by the copyltem component, depending on availability, it can be implemented by the in the 18 and 19 shown constellation come when both types of CNC machines and the processes assigned to them are still in the system.

The individual processes can suitably vary the task scheme as long as the dependencies with regard to synchronization are only reduced. In 20 For example, instead of the same policies contract, the two subordinate processes are each assigned a different policies contract. In contrast, is as in 21 violate the schema and there are additional dependencies, so there may be jams.

According to the example below 22 to 28 the basic idea on which the contract composition is based should be clarified. Starting from a set of basic contracts, which describe the relevant interactions and exchangeable data in an "orthogonal" area-specific manner, a multitude of services with different qualities can be derived by composition. Since the basic contracts are known to both service providers and service-requiring components, they form a common one Basis to determine whether the offered combination of basic contracts corresponds to a required combination The trader-based service connection based on the contract semantics then guarantees that all determined suitable contracts also meet the expectations described by the expected contract type.

As An example is the online ordering of books with different requirements described. In the following, the relevant basic contracts are considered first and subsequently a number of possible and meaningful combinations. The basic contracts represent the essential components available to even for combined contracts to be able to deduce the complete semantics.

In 22 the two alternative forms of book ordering considered in the example are defined on the left. The interactive version (OrderBookInteractive) allows iteratively to use search, select, getPrice and order operation to clarify whether the selected amount of books corresponds to the desired amount. Alternatively, the desired number of books to be ordered can be determined in the OrderBookQuery contract. In order to further determine the supplier address, there is also the EnterAddess contract.

To allow different types of payment, there are the basic contracts Ecash, CreditCard and Account, shown in 23 , The basic contract Ecash describes payment using an electronic means of payment. The credit card, on the other hand, can be used if the CreditCard contract is used. If there is a corresponding account with the contract provider, the account contract is another option.

The Delivery of any agreed service is further described by the Standard Delivery contract. As an extension there is still the UPDelivering special case, where as long as the delivery pending, the current status of the delivery can be queried.

in the more is now demonstrated using the example, as with help suitable contracts can be composed of the basic contracts, the allow contracts to be defined that are specific to the user or service provider needs suffice.

In 24 The first example describes the requirements of an ordinary book shop (BookShop) as an interface to wholesalers in its traditional form. This is ordered on the basis of a specific book request, whereby payment is made via an account with the wholesaler, the normal delivery closes the deal.

In contrast to this traditional approach, a BookOnDemand machine, for example, would exist on electronic means of payment and thus the ECash contract instead of paying by account (see 25 ).

An online book provider (OnlineBookShop), on the other hand, would like to be able to serve all conceivable online customers. Therefore, in our case, he offers all forms of selection (OrderBookInteractive; OrderBookQuery) and payment (Ecash, CreditCard, Account) as well as extended delivery with monitoring (see 26 ).

In order to open up all possible sources at the same time, the BookSource contract in 27 described that you are alternatively satisfied with either Ecash, CreditCard or account payment.

While in In the case of the OnlineBookShop contract, the offered behavior at the same time is offered and thus the contract user chooses the desired variant can choose is for the basic contracts for Payment in the BookSource contract only determines that one is achieved by them (alternatively) (autonomous contract steps).

Thus, the final result is in 28 possible contract connections indicated by the dashed lines, which show which suitable connections thus result in the system and which possible parts of the system could therefore do business with one another.

The BookShop can e.g. his books in addition to wholesale (BookProvider) also about Buy OnlineBookShops if this is attractive in terms of price is. The OnlineBookShop is able to, besides the wholesale also integrate BookOnDemand systems directly.

Of would be more it is conceivable that customers who special wishes have been able to target suitable providers. Would one Customer according to OrderBookQuery, EnterAddress, EcashPayment and StandardDelivery in the form of a combined contract, he would have given scenario e.g. the BookOnDemand and OnlineBookShop as suitable Trading partner.

credentials

• [Allen & Garlan 1997] R. Allen and D. Garlan. A Formal Basis for Architectural Connections. ACM Transactions on Software Engineering and Methodology, 6 (3), July 1997.
• [Buchi & Weck 1998] Martin Büchi and Wolfgang Weck. Compound types for Java. In Proceedings of the Conference on Object-oriented programming, systems, languages, and applications, October 18 - 22, 1998, Vancouver Canada, 1998.
• [Meyer 1997] Bertrand Meyer. Object-oriented software construction. Prentice Hall, 1997. 2nd edition.
• [Shaw & Garlan 1996] Mary Shaw and Davis Garlan. Software Architecture: Perspectives on an emerging discipline. Prentice Hall, 1996.
• [Szyperski 1998] Clemens Szyperski. Component software, beyond Object-Oriented Programming, Addison-Wesley, 1998.
• [UML1.3] Object Management Group, OMG Unified Modeling Language Specification, Version 1.3, June 1999. OMG document ad / 99-06-08.

Claims (19)

Method for operating combinable components in application servers, in which the behavior of the components of an overall system formed from the components is described by means of interfaces between individual components on the basis of contracts, characterized in that, in addition to the syntactical interface description, a behavior log for each contract is used to describe each component is used, which describes the properties of the component with regard to the synchronization between the components via the respective contract, an internal dependency relation is used to describe the dependencies between the offered and used contracts, which uses restricted contracts that only block the contract user unilaterally Contract providers, which describes dependencies within the component between the offered and used contracts and allows them together with the contracts, A Exclude normalities in the synchronization of the component with other components of the overall system, by means of application servers and / or operating system components, synchronization anomalies of the combinable components during the operation of the components can be prevented or diagnosed by the dependency relation when combining components by linking the individual dependency relations of the Components are created, checked for cycles. Process for the design of combinable components in application servers, in which the behavior of the components of an overall system formed from the components is described by means of interfaces between individual components on the basis of contracts, characterized in that, for the description of each component, in addition to the syntactical interface description, a behavior log for each contract is used, the properties of the compo describes the synchronization between the components via the respective contract, an internal dependency relation is used to describe the dependencies between offered and used contracts, which uses dependencies by means of restricted contracts, which can only lead to a one-sided blocking of the contract user by the contract provider describes within the component between offered and used contracts and together with the contracts allows to exclude anomalies in the synchronization of the component with other components of the overall system, and to prevent or diagnose synchronization anomalies of the combinable components at the time of design by means of development and / or programming tools, by checking the dependency relation when combining components, which is created by linking the individual dependency relations of the components, on cycles. Procedure according to a of claims 1 or 2, characterized in that by means of the behavior logs an efficient test for connectivity for combined from basic contracts Contracts carried out is by the states of the combined contract is described as a combination of the basic contract conditions become. Procedure according to a the preceding claims, characterized in that for explicit synchronization for a lot of contracts offered and used about that general contract behavior restrictions going beyond be specified. Method according to claim 4, characterized in that a behavior offered by a contract only from one used Contract dependent can be made if this is the dependency relation of the component allows. Procedure according to at least one of the claims 4 or 5, characterized in that one component controls the operation of offered contracts only of inquiries or behavior contracts used if this use is guaranteed upon acceptance of the guaranteed behavior becomes. Procedure according to at least one of the claims 4 to 6, characterized in that the behavior of a component that in the associated Behavior described in multi-contracts corresponds. Procedure according to at least one of the claims 4 to 7, characterized in that a defined further Synchronization is then guaranteed will when the different contracts offered as well as parallel Inquiries are processed fairly by the respective component. Procedure according to a the preceding claims, characterized in that at Combination of components the amount of multi-contracts and the contracts involved that are not further restricted by multi-contracts result in behavior that is free of deadlocks and infinite internal activities is. Method according to claim 9, characterized in that the Combination of components to form a suitable composition allowed in the form of a new component, being used for overlapping quantities of multi-contracts applies that this may have internal and / or external components and in the case of the presence of both internal and external components a corresponding abstract multi-contract of the newly formed component exists that abstracts from the behavior of internal contracts. Procedure according to a of the preceding claims 1 to 10, characterized in that the behavior of the components is checked for contract conformity at runtime of the overall system. Procedure according to a of the preceding claims 2 to 10, characterized in that the behavior of the components is checked for contract conformity at the time of design of the overall system. Procedure according to a the preceding claims, characterized in that by means of Applications or modular application architectures synchronization anomalies of the combinable software components during their operation or at Configuration or adding prevented or diagnosed by software components. Procedure according to a the preceding claims, characterized in that by means of Search in component archives and / or offered through intermediaries (traders) Contracts suitable components or contracts for exchange or Connection determined become. Procedure according to a the preceding claims, characterized in that by means of Applications or modular application architectures violations the specification and thus the possible occurrence of synchronization anomalies becomes. Method according to one of the preceding claims, characterized in that by means of tools for test creation and test execution possible violations of the specification are generated with the help of contracts for given test cases or test generators by combining and simulating the protocol. Procedure according to a the preceding claims, characterized in that at the behavior log of a contract in addition to the pure process of calls and their restrictions (non uniform service availability) assigned to this behavior declared states become. Procedure according to a the preceding claims, characterized in that the Formation of new types of contracts by combining given ones and addition of new contracts is made, focusing on the semantics the combined contracts by using the states and Operations. Design and / or operation methods that can be combined Components according to one of the claims 1 or 2, in which the behavior of the components is one of the components formed overall system by means of interfaces between individual Components are described on the basis of contracts, thereby characterized in that the Coupling of contracts at runtime of the overall system only then is allowed and / or brokered when combined from base contracts Contracts where the states of the combined contract is described as a combination of the basic contract conditions be regarding of behavior logs an efficient test for connectivity successfully completed becomes.