1

page 1 (7 pages)
		2

AFNOR comments on DIS 10746-3 - Annex

0 Introduction

From the lively debate which took place between the various national bodies about bindings, the following conflicting questions appeared:

1- Do we need a binding object?
In case we do, do we need to make it visible in the computational viewpoint?
2- Do we need to allow binding objects to have interfaces?
Does that create a non-terminating recursion problem?
3- How can we distinguish bound versus unbound interfaces?
4- Do we want to include in the computational viewpoint some semantical way to support end-toend QoS constraints?
In case we do, how signals and binding object notions are affected?

We first introduce and explain the AFNOR proposal which is the most complete. Then we summarize each of the alternatives and contrast it with this solution, trying to weigh the advantages and the drawbacks. Paragraph 2 alternative is called A1 whereas paragraph 3 thesis is called A2. Every solution is analysed according to its answer to the previous "conflicting" questions.

1 A generic binding process creating a binding object.(AFNOR)

1.1 Main characteristics

This solution is mainly based on the notions of binding objects and signals as they are introduced in the present DIS document. This would only require in the present document to add an explanation of a generic binding process that would fit in the "Binding rules" paragraph. In this solution, an explicit binding is materialized in the computational model by a visible binding object which nature is not different from that of a computational object except that it supports binding interfaces which are essentially signal interface and have a synchronous communication semantics. The generic explicit binding process below explains in computational terms the instantiation mechanism of an explicit binding. It must be understood as an example of such a binding process, of how it could be built and not at all as a standard proposal.
In this proposal we do consider that interactions between a basic computational object and a binding object are composed of atomic actions called signals which are semantically synchronous (i.e.: instantaneous) instead of being asynchronous like operations.

1.2 An example binding process

The generic explicit binding process could have the following sketch:
(a) locate a binding object factory of the appropriate type;
(b) request the creation of a new binding object (possibly by passing identifiers of interfaces to be bound);
(c) obtain in return binding interface identifiers and control interface identifiers; (d) locate "link" interfaces corresponding to the interfaces to be bound;
(e) pass binding interface identifiers to the relevant "link" interfaces thus completing their binding.

One can have a one-to-one association between "link" interfaces and interfaces to be bound explicitly. In this case, it is possible to hide step (e) in the generic binding process described above, only passing "link" interface identifiers to binding object factories in step(b), relying on some engineering mechanism to relate "link" interface identifiers and the interfaces to bind and to perform step (e). The specifier thus need not to bother about "link" interfaces and binding interfaces of the binding object. From the computational specifier, all these steps can be provided by a local "Binding server". An explicit request to the Binding server may have the following form: Bind(M1,M2,M3,T) where M1, M2,M3 denote identifiers of link interfaces corresponding to the computational interfaces to be bound. This sketch is explained step by step with an explanatory figure below.

An example of generic binding process step by step:

4 4

AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA

AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
Binding
factory
(type t)

AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA

Object 1 binding
object

AAAA
AAAAAAAA
AAAA

AAAA
AAAA
AAAA
AAAA
AAAA AAAA
AAAAAAAA
AAAA

AAAA
AAAA
AAAA
AAAA
AAAA

bind(M1,M2,
M3,t, c1,c2)
link(a,u)

c1 c2

a b
c
u v

AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA

AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
AAAA
Binding
server

M1 M2

link(b,v)

link(c,w)
Object 3

Object 2

create-bind-obj
(M1,M2,M3)

Fig. 1 binding process

- binding object: object in charge of the binding of several interfaces. this object has a type that defines its configurations and its characteristiques.
- binding factory: object in charge for the creation of a binding object of a certain type - binding server: object in charge for looking for the correct binding factory
- T the type of binding object required.
- u, v and w are the interface references that have to be bound
- a,b and c: interface references of the binding object that will enable the binding of the interface references u,v and w
- M1, M2 ad M3 : interface references able to receive a 'link' operation on the concerned objects (Object 1, 2 and 3)
- C1 and C2 : control interface references of the binding object.

Step 1 - one object invokes the operation

bind (M1, M2,M3,t, return c1,c2) on the binding server that is in charge for looking for the correct binding factory. This operation asks for the binding between several interfaces using a binding object of a certain type.

Step 2 - The binding server invokes on the correct binding factory object create-bind-obj (M1, M2,M3,T)
This operations asks for the creation of the correct binding object.

Step 3 - the binding object of type T is created

Step 4 - the binding factory invokes on the M1, M2, M3 interfaces references respectively the operations link (a), link (b), link (c),
This operation asks for the link between the corresponding computational interface to be bound and the binding interface [and gives if they are necessary to the concerned object, the control interfaces of the binding object].

1.3 Remark

Establishing a binding provides a computational object with an identifier for a binding interface. Having an identifier on a binding interface is enough to assure that communication is possible and that there is a binding. Having an identifier for an operational interface also means that it is possible to communicate with it directly. Therefore it is an obvious answer to the third question and we think it is useless to use a different terminology for bound and unbound interfaces as requested by the Australian body. What the model implies, therefore, is an explicit identification of the binding interfaces. Whereas possessing a (remote) signal interface identifier would only allow invoking a notional "link" operation, communication is possible as soon as the corresponding interface to be bound receives, as a result from the link operation, an identifier of the signal interface which is its private binding interface.

1.4 Motivations

This solution which is certainly the most complete of all the proposals gives us powerful means to deal with explicit bindings in the computational viewpoint:

- First, it enables us to control distributed object configurations. The basic mode of communication in ODP is interaction with known interfaces. However, a number of objects, particularly those interfacing physical artefacts (e.g. audio, video boards, switch matrix, robot effector,etc...) are built with only limited knowledge of their environment. Typically, they can only interact, at any time, with a limited number of other objects (a constraint often materialized by the presence of a definite number of communication ports). Using these objects, implies placing them in meaningful configurations (e.g. connecting their ports to appropriate producer or consumer interfaces). Such explicit control over object configuration is the rule in numerous applications such as multimedia applications and telecommunication applications.

- Second, basic communication patterns are limited, on purpose (for the sake of minimality and simplicity), to simple operation invocation. However, communication patterns between objects may be quite varied, ranging from multi-point communications to conferences or tuple-space communications. One should be able to build these communication structures, perhaps using particular features of the environment (e.g. multi-point addresses or a broadcast transmission

medium), and to make them available for use by application objects as special classes. Binding objects seem to be a good manner to instantiate at any time suchreusable mechanisms.

- Third, this solution is an answer to the need, in distributed applications requiring definite quality of service guarantees for their execution, to provide control of QoS constraints and of their associated infrastructure support. Managing QoS can be considered as establishing a contract between requiring applications and providing infrastructure. This contract needs to be made explicit somehow for the infrastructure to provide expected guarantees. This implies both means to express these guarantees, some template to hold them, and explicit interfaces at which to control (e.g. monitor, benotified of, modify, etc...) them. We believe that binding objects are a good opportunity to encapsulate this explicit control of the QoS. Indeed, since proxies (i.e. private binding interfaces) are considered to be local w.r.t. the proxied interfaces (i.e. the computational interfaces to be bound) and since communication between proxied and proxies is considered to be synchronous (i.e.instantaneous!) , the QoS provided by the communication structure is end-to-end.

2. No binding object is visible in the computationalviewpoint (alternative 1)

2.1 Main characteristics

On the contrary to AFNOR solution, A1 solution does not relate the notion of Binding object with the notion of signal considered as the basic synchronous interaction between a basic computational object and a "distributed" binding object.
This proposal separates the interaction concepts from the binding management concepts and describes interactions without reference to binding objects. There are three kinds of interactions: operation, stream and signal. A1 would like each of them to be defined independently of each other with optional pathways between them.

The generic explicit binding process
When an interface is created, it receives an identifier which is used for implicit binding. In the perspective of explicit binding, a "binding manager" is also created and receives anidentifier for its interface. This "binding manager" supports operations that accept identifiers for computational interfaces and create bindings to those interfaces. When an operation is invoked on the "binding manager" interface, the return result is an interface identifier for interactions relative to the computational interface w.r.t. the established binding plus a control interface for the binding. Binding managers can "engage inall sorts of chatter with other binding managers including up calls to applications to enable application specific binding policies". Therefore the interactions between binding managers and other computational objects give all the expressiveness we expect for bindings in the computational model. We could argue that the first two motivations for AFNOR first proposal are also satisfied by A1 proposal.

Fig.2: A1 proposal

2.2 Advantages and drawbacks of this solution

A1 says that eliminating the binding objects gets rid of an "unnecessary formal scaffolding" and leaves the specifier away from implementation details. However we do think that A1 proposal can easily be explained in the terms of the AFNOR first solution but has the drawback of leaving obscure some important points. In terms of AFNOR first solution, the binding manager interfaces correspond to a combination of both binding object factory interfaces and "link" interfaces.

- When invoking a binding manager interface, two things happen: a binding object is created, and a binding interface identifier plus a control interface on the binding are returned. However, the underlying bindingstructure which would correspond to a binding object is not defined in the computational viewpoint but is to be understood by looking at the engineering model. On the contrary, in AFNOR's solution, the computational model is explained without any reference to an engineering story, i.e. the computational semantics is fully defined.

- The binding manager interface appears to be an interface on the object supporting the "proxies interface". Unless one were to consider some form of generic binding interface (possibly resulting in a type-unsafe situation), objects should support a different type of binding manager for each type of binding that can exist. The scheme proposed by AFNOR avoids these difficulties by requesting only the presence of a single "link" interface per object or per interface to be bound and leaving the task of creating bindings of arbitrary type to specialized binding object factories.

- Binding managers "can engage in all sorts of chatter with other binding managers ... including up calls to applications to enable application specific binding policies etc...". While this is certainly possible, it is not saying much! Suppose we were only to say, at the computational level: there are binding manager interfaces; they can interact with arbitrary objects in various ways; they result in bindings being established. Obviously the computational viewpoint would be very fuzzy and incomplete. We would have to resort to a detailed description of the engineering model to understand what we mean by binding computational interfaces.

- A1 solution does not relate the notion of binding object with the notion of signal considered as the basic synchronous interaction between a basic computational object and a "distributed" binding object. In our sense, this is an important drawback since it does not enable us to deal with QoS control in the computational viewpoint. Again we have to resort to a detailed description escaping from the computational model if we want to understand how QoS constraints can be expressed and infrastructure guarantees be provided. On the contrary, AFNOR solution enables us to express endto-end QoS guarantees encapsulated by binding objects since proxies or binding interfaces are considered as being always local w.r.t. their "proxied" computational interface and the communication between proxies and proxied is considered to be synchronous.

3 A2 thesis

As AFNOR's solution, A2 agrees that binding objects and signals are the fundamental basis for the explicit binding between basic computational obects. However the A2 thesis differs from the AFNOR's on several points:
- First, A2 supposes that the binding objects and the basic computational objects are not of the same nature. As a matter of fact, AFNOR thinks that basic computational objects and binding objects are very similar. The only difference is that binding objects support binding interfaces which have a special communication semantics: they interact synchronously with their corresponding computational interfaces to be bound. A2 also supposes that the binding objects

don't have computational interfaces. AFNOR's proposal, on the contrary, lightens the fact that binding interfaces of binding objects are a special case of computational interface ( they are signal interfaces ). Somme people think that binding interfaces generate a non-terminating recursion problem. However, this recursion problem is an illusion! One can always stop the recursion with a plain old operational interface at which one can bind implicitly. One can also allow binding objects without control interfaces. In order to solve this recursion problem (which is not a problem in our opinion), A2 does not talk about binding interferaces. Instead it says that binding objects have roles which are just there to be "plugged into" by interfaces of basic computational objects. But it does not solve our basic problem, ie what does it mean for several comutational objects to be bound by a binding object. Refering to the roles is just another way to express that binding objects have binding interfaces (according to part 2 terms, an interface defines a specific role and conversely plugging into a role is just an informal way to say that this role defines an interface). - Second, A2 considers operations as a transparency over signals enabling specifiers to avoid a certain level of complexity when they want. It is certainly exaggerated to speak of a transparency. In fact, using operations does not mask anything. It is just mandating some specialized form of interaction.

4 AFNOR proposed alternative to A1's proposal

(simplified solution that we consider as a minimum)

Even, if we prefer the first AFNOR proposal, we propose here an alternative to BSI's solution. No signals between binding interfaces and proxied interfaces (asynchronous structure of communication between computational objects)

4.1 Description

It is possible to simplify our first proposal at the price of having a much poorer model. We consider a computational specification as a set of computational objects interacting asynchronously through operations or streams. There isonly one binding process considered in the model: the implicit binding. We can build on top of the model explicit binding objects by composing computational objects representing proxies of computational interfaces. There is no formal difference between a basic computational object and a binding object.

Fig 3. AFNOR alternative to UK proposal

The signal notion becomes redundant with the operational announcement inthis case.

4.2 Advantages and drawbacks

As in the first proposal, we have here a completely defined semantics for the computational model. The two first motivations of the first proposal are also fulfilled by this one. It enables us to control distributed object configurations which is very useful in numerous applications (multimedia and

telecommunications applications for instance). It also provides us with a mechanism of instantiation of a reusable communication pattern encapsulated in a specialized computational object.
However it is impossible to have an explicit control of end-to-end QoS constraints only in the terms of the computational viewpoint which might be very limiting for specifiers. Indeed, compared to the first AFNOR solution, there is no more way to encapsulate in a computational language object an end-to-end QoS constraint

Somehow, this solution seems better in our view than BSI's one because the semantics is completely defined. It is easy to derive a formal description of its semantics from the more general semantics of the first proposal.

5 Conclusion

We analysed and compared the alternative solutions which seemed relevant in our view. We hope that it lightens the fact that we need the notion of binding object combined with the notion of signal which enable us to deal easily, in particular, with end-to-end QoS constraints.

We presented an alternative AFNOR's simplified solution that we consider as a minimum. It is preferred to BSI's proposal because we do think that it offers the same level of expressiveness but is based on a semantics completely defined in the computational model. However we definitely prefer the first solution.