Course notes by Gregor v. Bochmann, University of Ottawa
Software components and interfaces
- Component-based software architectures: small components (object
classes), big components (frameworks, etc. - collection of classes and instances)
- Properties of components and systems
- Properties of an "object instance" is usually defined by the class
to which it belongs. There are different
kinds of properties
that must be specified.
- As indicated for the interface specification (see above), the specification
of an object or a component consist of two aspects: assumptions that the
components makes about its environment, and the guarantees that its behavior
provides to the other components in its environment. Note that the environment
may include the "users" and other system components. The requirements S that
a component then must satisfy is the following: if the assumptions A are
satisfied then the guarantees G are provided, or in logic notation: S = (
A => G ) . (See also slides 1 through 3 in
Assumption-Guarantee Specifications
).
- If another specification S' implies S, written S' => S, we say
that S' is stronger than S. If S defines the requirements for a component
C then for any correct implementation I of that component, if S' are the
properties of that implementation, then it should hold that S' implies S.
This means that the assumptions of I are weaker than those of requirements
and the guarantees are stronger than those of the requirements (See also
slide 4 in Assumption-Guarantee Specifications
).
- If a system works correctly with a given compoent C that has the
properties S and another comonent C' has the properties S' and S' =>
S, than the component C may be replaced by C' and the system will still
work correctly. (See also slide 5 in
Assumption-Guarantee Specifications
).
- If a system consists of several components then the properties
of this system is simply the logical AND of the properties of all its components.
(See also slide 7 and 8 in Assumption-Guarantee
Specifications
).
- Application programming interface (API)
- interface of methods that can be called (for passive and active
component)
- definition of what other components are called with what method
calls
- event-oriented programming
- CORBA IDL: A language-independent definition of interfaces. An IDL
interface definition can be automatically translated into interface definitions
in Java, C++, etc. (see also RPC module
)
- Service directories
- The same concepts (defining the properties of a comonent that provides
some service) are used in Web
services
. In this context, the objects reside in servers and the services defined
by their interfaces are accessible over the Internet. There is a Web Services
Description Language (WSDL) which can be used to define the interface of a
Web Service, the same way as a Java langiuage can be used to define a Java
interface (which defines an interface that can be implemented by a class and
all objects of that class.
- The Web services environment also includes directories in which
the services provided by given objects can be registered and potential users
can search such directories in order to find an object that provides the
service the user is looking for. The search can be performed according to
the type of the service interface (possibly considering subtyping) and according
to desired values for certain attributes that are defined for the service
interface in question. In the context of Java, the Jini directories provide
the same kind of directory service. Note: The
Globus Alliance
has developed a tool kit that provides easy translation from Java class
interfaces to WSDL service descriptions and a corresponding implementation
envionment for the protocols used for Web Services (see also
RPC module
).
- An example of a system using such facilities is our ongoing Canarie
project on
User-Controlled Lightpath Provisioning
(see slide
number 20)
- Open Distributed Processing (ODP) << see [Blair &
Stefani], Sections 2.1 through 2.3 >>
- This was a major standardization effort within ISO which later
led to the development of CORBA.
- Different viewpoints
at different levels of abstraction were defined.
- Different transparencies
were considered as goals for future standardization.
- Called interfaces and calling interfaces
- The interfaces discussed above a "called interfaces" (they define
what method can be called on this object). Similarly, one may define for
a given object (or object class) a "calling interface", that is, a description
of the methods that are called on another system component.
- Then a calling interface may be connected with the "compatible"
called interface of another object. The compatibility of such "connections"
may be checked with the different system components are combined. (Note:
this is the same as type checking performed by a Java compiler).
- Stream interfaces << this approach has been elaborated in Chapter
3 of [Blair & Stefani] >>
- In addition to interfaces providing the possibilities for method
calls (called operational interfaces), a MM source or destination may also
have interfaces through which a multimedia stream is received or sent (called
stream interfaces). Example: A camera may be switched on and off through
an operational interface, and when ON, it will send a video stream through
another interface.
- As operational interfaces are characterized by available methods
and their input and output parameters, a stream interface is characterized
by the type of media send (or received) and the encoding structure of the
media.
- As for called and calling interfaces, sending and receiving stream
interfaces of diffrerent system components may be "connected" if their respective
media types are compatible.
Last updated: September 8, 2003