Contribution to Open Distributed Processing ------------------------------------------- -- Interface References and Binding ------------------------------------ We recommend the following changes in the current working document "ISO/IEC JTC1/SC21 N10430 Open Distributed Processing -- Interface References and Binding". General comments and motivation ------------------------------- 1. The current document does not include any solutions for federation problems. Instead, the document indicates a series of relevant problems and constraints for the solution. The federation problems must have a schematic solution before the document can proceed to CD ballot. 2. The viewpoint specifications are not yet written in an appropriate viewpoint language style. Instead, all text seem to be computation oriented. In the detailed comments we present a sequence of text corrections in order to decrease this problem. 3. The information viewpoint specification does not yet indicate what are the potentially dynamic schemas for the binding functionality. This is an important aspect, because several existing distributed systems, such as CORBA, can be in some extent be conformant to this specification. From the conformance point of view, several requirement levels should be indicated via the introduction of dynamic information schemata. 4. The most fundamental feature under consideration in this standard is the federation of systems in binding establishment. The ODP-RM aims for interoperability both within and between sovereign organisations. Therefore, information related to an established binding must be present at several involved computing systems. Therefore, in this context, distribution is a relevant system feature from the information point of view. 5. In computational viewpoint, distribution must be presented because it has a direct reflection on the suitable abstract mechanism. If federative behaviour is not represented in this viewpoint, no interworking reference points can be expressed and conformance requirements can not be stated. 6. The scope of this standard includes also a technical representation for interface references for transfer between systems. Because it is a technology restriction (each system should conform to it at a portability reference point, either by directly supporting this syntax or by providing an interceptor to meet the same data format), it can be included as a technology viewpoint aspect. 7. As the final major point we would like to point out a contradiction in the selected modelling concepts. In the current document there is no clear distinction between the concepts of liaison, binding (noun), and a channel. These terms seem to appear almost as synonyms in the text. However, the liaison is a very abstract concept (form ODP-RM Part 2) that only expresses that a common contractual context has been established. A binding is one of the more concrete forms of a liaison: a binding is a contractual context where the contract is about aspects of communication capabilities in use. A binding is a computationally oriented concept. A channel is an engineering level concept and involves resource reservation etc. A channel can be reconfigured, for example, because of optimisation, migration, failure recovery, etc. In the reconfiguration process the original channel is destroyed and a new channel is instantiated. In reconfiguration of a channel, the binding may or may not be destroyed and recreated with a different identity. If the contract between the communicating parties is not changed, the binding stays intact. If the binding, i.e., the contractual context includes several alternative methods that can be used for channel engineering, the binding can be re-established without violating the liaison. A very flexible liaison is relevant for inter-organisation federations at the middleware service level. Detailed comments ----------------- Item: 8 Level: editorial Clauses: 7 Rationale: Structuring rules of enterprise viewpoint given by ODP-RM Part 3. Suggestions: a) Remove sentences of clause 7.4. at page 7, except the sentences "The roles of initiator and target can be combined." and the last one that continues as a bullet list on the next page. b) Move the binding pre-conditions from clause 7.1 to clause 7.4., under obligations of binding factory. The binding factory is obliged to check that the preconditions for binding are fulfilled. c) In clause 7.3. give a clause number for each activity: 7.3.1. Binding, 7.3.2. Unbinding, and 7.3.3. Binding management. d) Move paragraphs of clause 7.1 at page 4 to clause 7.3.1. e) Move the second bullet list of 7.1. at page 5 to clause 7.3.1. f) Add a sentence to clause 7.3.1. In explicit binding, a control interface is created. This interface is the location on which binding management activities occur. g) Move the third bullet list of 7.1. at page 5 to clause 7.3.3. Item: 9 Level: modelling Clauses: 7 Rationale: See comment #7 Suggestion: a) Replace in 7.2 "binding object/channel" with "liaison". Replace in 7.2. "target" with "target interface". Add in 7.2. "channel". A channel is the concrete, technical realization of a liaison and is necessary for the communication to occur. The liaison has two alternating epochs, one where a channel is reserved and configured, and another where only information for the creation of a channel exists. b) Give clause numbers for each role: 7.2.1. Initiator, 7.2.2. Target interfaces, 7.2.3. Binding factory, 7.2.4. Liaison, 7.2.5. Channel. c) Add to clause 7.2.2. a couple of sentences to indicate that there are stream interfaces and operational interfaces. d) Split the clause 7.1.1. in two parts: the former part is moved to clause 7.3.1. and the latter part is moved to 7.4. The former part describes the purpose of the stream interface binding. The latter part describes the obligations and permissions of binding factory in case of stream interface binding. Item: 10 Level: technical Clauses: 7 Rationale: Editor questions at page 8. Suggestion: a) Add activity "binding monitoring" as clause 7.3.4. Binding monitoring is an activity of the channel object. It reports contract violations during communication to the communicating partners, and potentially to the initiator (who holds the management interface). b) Add consideration of quality of service aspects and other contract negotiation aspects to clause 7.4. The binding factory is obliged to check that the interfaces have such quality of service properties available as the peers require. Security requirements are part of the quality of service attributes. Item: 11 Level: modelling, editorial Clauses: 7 Rationale: The illustrations are difficult to follow. The drawing technique does not allow simulation of time. A drawing of a community should clearly separate which objects are present simultaneously. Suggestion: Identify two epochs for the community. One of the epochs shows how the initiator is bound to the binding factory. The other epoch shows how the targets are bound to the liaison object. A third epoch shows how the liaison object is supplemented with a channel object. Item: 12 Level: modelling, technical Clauses: 8 Rationale: See comment #4 Suggestion: For each information object there should be statements about the domain in which they are interpreted. Add the following statements: Environment contract is a non-distributed object. An environment contract can be transported to another node, but in that case the information contents must be portable. An environment contract is available for each client and server role interface. A binding template is a distributed object that contains instructions for a set of nodes in which the target object interfaces are present. There must be a local copy of the binding template in each of the nodes. In each node the representation of the binding template is transformed to a format that is consistent with the local platform and network service concepts. In order to be able to participate in reconfiguration of the binding, the node must be able to retrieve a transportable form of the binding template. Interface reference is a non-distributed object. Interface references are transported between nodes and need to have a transport format that can be interpreted in each node. Interface reference is the part of the binding template that describes the liaison in effect from the point of view of a single member object in the binding. The liaison information is available only for those objects involved in the binding or supporting the binding. Item: 13 Level: editorial Clauses: 8.3 Suggestion: Move "opaque information" and "interpreter reference" close together and add a sentence that indicates that these two items together identify the interface. Item: 14 Level: modelling, technical Clauses: 8 Rationale: See comment #3 Suggestion: a) Static schemata Interface references may not contradict the constraints set by the environment contracts. Interface references live as long as the binding is in effect. b) Invariant schemata The interface identity, role and the interface type do not change during the life-time of the interface reference, i.e, during the life-time of the interface. c) Dynamic schemata Rebinding between target interfaces causes the removal of the channel object and recreation of a new channel object. The information contents of the existing interface references is changed, but the binding is not recreated. Item: 15 Level: technical Clauses: 8.3 Rationale: Management of group communication Suggestion: Add a new item to the information contents of interface references: a reference to a group controller. Item: 16 Level: technical Clauses: 8.3 Rationale: Conformance of interfaces for rebinding Suggestion: Add a causality statement (role) to the interface reference structure. Item: 17 Level: technical/editorial Clauses: 9 Rationale: The overview, the enterprise viewpoint specification, and the computational viewpoint specification are contradictory. The contradiction arises from the information fed to the binding process. In the first two chapters, the binding process is obliged to select the interfaces. In computational viewpoint, the binding process starts from identified interfaces. Suggestion: Include selection process also to the computational viewpoint. Item: 18 Level: modelling Clauses: 9 Rationale: In the meeting in Kansas City the group noticed the need for specifying activities for computational viewpoint. The idea was to follow the example of naming framework standard. Suggestion: Activities related to binding and interface reference management: - create a binding (binding for the first member) - join to a binding (binding for others) - rejoin to a binding (rebinding) - delete a binding (end a liaison) - leave a binding (unbinding for any group member) - create a channel (the abstract binding receives resources) - transfer a binding template (each node needs a copy) - create an interface reference ... or is it an environment contract? - transfer an interface reference ... or is it an environment contract? - compare interface references (are we bound to the same target?) For the introduction of these functionalities the computational viewpoint need to have the current protocol description, but in addition the computational viewpoint need to be refined in order to show nodes and their federation interfaces. The refinement step in this case does not introduce new objects, it needs to abstract the federation situation to nodes only. The essential aspect in the computational specification is to show that the information in use is heterogeneous and also need to be transfered to the correct place for negotiation. These aspects are more important than just engineering viewpoint decisions. In some middleware solutions (CORBA, TINA) this is not apparent, but the ODP binding frameworks should be able to create connections also between different type of middlewares, for example, to create bindings between CORBA and TINA objects. Material for the above listed functionalities can be found from the working draft annexes and ODP-RM Part 3.