Component technology
Many applications, for example in the area of telecomputing, banking and multimedia (but also in high performance computing and operating systems), require support for distribution and concurrency. Due to their complexity, these applications are likely candidates for an object-oriented approach. However, with regard to their distributed nature, some marriage between object-oriented computing and distributed computing must be realized.
Component technology
- objects versus components -- definitions
- interoperability
- requirements for distribution
- a simple workgroup application
- extending hush with CORBA
Additional keywords and phrases:
(D)COM, Java, CORBA, OLE, persistent objects, ODMG, workgroup
Objects versus components
subsections:
As observed in
Definitions
Object orientation has not quite fulfilled its promise with respect to reuse. One of the reasons for this is that objects are generally not as modular as they might appear. Or, in the words ofComponent
- unit of independent deployment
- unit of third party composition
- no persistent state
Object
- unit of instantiation
- (persistent) state
- encapsulation of state and behavior
Let us look at the definition of software component
given in
A software component is a unit of composition
with contractually specified interfaces and
explicit context dependencies only.
A software component can be deployed independently
and is subject to composition by third parties.
This definition was the result of an ECOOP96 Workshop on Component-oriented Computing. Notice that the definition itself contains a reusability requirement, in mentioning composition by third parties. The requirements of explicit context dependencies, the absence of inherent state and contractually specified interfaces only strengthen this.
In contrast, an object is not a unit of deployment,
but a unit of instantiation.
Objects are not used in isolation.
Objects, do have state and identity.
Deploying an object or a collection of objects, moreover,
is often subject to (implicit) assumptions
concerning the interaction of objects.
Components as better objects
Reconsidering the definitions given,
I tend to think of the distinction between
components and objects as a distinction between
perspectives.
From a deployment perspective we need components.
From a developer's perspective we might prefer to speak
about objects.
Unfortunately, matters are not that easy.
But we need to take a closer look at the technology
to find out why.
The technology matrix
The component technology field is currently dominated
by three players:
Microsoft (D)COM,
OMG CORBA,
and (the youngest player)
Sun Microsystems Java.
When comparing these technologies with respect to attributes
such as
distribution,
mobility,
language and platform independence, and
reflective capabilities,
we see that there are many differences.
First of all, notice that component technology does
not automatically mean distribution.
For example, JavaBeans and Microsoft COM do not support
distribution.
Secondly, whereas language independence seemed to be
of importance in the pre-Java era, that is for (D)COM and CORBA,
it is not so for the Java-based solutions.
Finally, platform independence is hard to achieve.
But, fortunately, it is on the agenda of all three
technologies, including (D)COM.
It is worth mentioning that the three major technologies have a rather different origin. Microsoft (D)COM is primarily a desktop technology, with Office as its killer application, whereas CORBA originated from the need to have an enterprise-wide solution for distributed objects. Java is a special case. It started as a Web-based language, but rapidly took position in the desktop and enterprise world as well.
Java distinguishes itself from the other technologies
both with respect to mobility and reflection.
As a Web-based language, Java allows for downloading
code dynamically, that is class descriptions for instantiating new
objects.
True mobile objects,
that is instantiated objects that migrate themselves,
are only possible when using a system such as Voyager,
or any of the other Java-based agent ORBs.
Java also provides a powerful Reflection API,
which allows for various kinds of meta-programming,
including the creation of new classes.
In comparison, meta-programming facilities of
the two other technologies are limited
to querying the availability and functionality of interfaces,
dynamic method invocation
and some dynamic typing.
Trends -- interoperability
An interesting project in this respect is the
K-Office project,
which aims at developing an Office Application Suite for the
Unix/X11 desktop.
It is built upon the KDE GUI environment,
and employs a CORBA-based component technology,
(nick)named KOM, to interconnect
(embed and link) the various document components
and their associated tools. See http://koffice.kde.com .
if semantical issues can be resolved
development becomes more complex
it affects performance significantly
wrong, it is an evolution from OO and C/S
unknown source
And, as indicated in slide myths,
do not underestimate the complexities
of developing such applications.
Given the failure of many OO projects, as described in
Yet, in conclusion,
just as object orientation may be regarded as
a natural evolution from data-oriented approaches,
we may look at component-oriented approaches
as a natural evolution from object orientation into
the realm of distributed systems.
The object-linking technology allows
the user to maintain a link from one application
to another,
so that for example a text processor may
directly employ the results of a spreadsheet.
Moreover, object linking is dynamic and allows
any updates in the spreadsheet application
to be reflected
directly in the outcome of the text processor.
In contrast, object embedding works more as
the traditional cut and paste techniques
in that it results in including only a copy
of the material.
To be embedded or linked,
applications must satisfy a standard programmatic interface.
In effect, the interface must provide the facility
to request an update of the display
of the information contained in the application.
In this respect, the OLE technology may be characterized
as document-centered.
In this section, we will look at the Java platform from the
perspectives listed in slide Perspectives.
The rhetoric in these reflections must not be misunderstood
as dismissing Java, but as a way to get hold
of the issues that play a role in adopting the Java technology,
or any of the competing technologies, for business-critical
applications.
Now back to the reality of software development.
Many Internet applications are written in script languages.
Perl for server-side scripting and
Javascript on the client-side.
Given the efficiency problems of Java
(which are a consequence of the virtual machine approach)
and the long download times for applets,
Java runs the risk of being too light for
heavy-duty servers and too heavy for lightweight clients.
In terms of research, what Java offers is not really new.
Personally, I am somewhat disappointed
that the attention is focused on another third-generation
language,
whereas to my mind, we should have a declarative programming
technology on our research agendas,
a technology that supports the development of reliable and
verifiable software.
Nevertheless, Java appears to be an excellent platform for
Web-related research.
An example of a business application framework
is the IBM San Francisco framework,
discussed in
section San Francisco,
which offers generic solutions for the realization
of business processes, such as order management and quality control.
Nevertheless, crucial issues in this area do not seem
to concern technology per se,
but rather the standardization of such notions
as business objects, business processes and, of course,
business logic.
This is also an area of active OMG interest.
The object model guiding the implementation
is depicted in \sliref{object-model}.
The most important notion in our system is that of an agent,
which is defined as a representative of a user which can perform
simple operations on the user's behalf, such as sending messages
to and making appointments with other agents.
Each user participating is represented by a personal
agent, which has an agenda and a message queue. Each agenda consists
of several appointments. A workgroup has a membership list consisting
of zero or more agents present in the system. An agent can be
a member of zero or more workgroups.
Possible operations on agents are sending messages
to and making appointments with other agents, subscribing to a
workgroup, making an appointment with a workgroup or sending a
message to all workgroup members.
All interaction of the user with the system is done
via Java applets, which combine a graphical user interface with
Internet access and CORBA functionality. The server is implemented
in C++. We used Visigenic's (formerly PostModern Computing)
CORBA 2.0-compliant product ORBeline
to implement the server and BlackWidow from the same vendor to
implement the Java clients. The server can run on most UNIX platforms,
as well as on Windows NT, while the Java applets, running on top
of a Java Virtual Machine, can theoretically run on every platform
that Java supports. In addition, a C++ browser/monitor was developed
that can be used to interrogate agents and workgroups and to monitor
message flows.
The Java client applets are first transferred to
the client by the HTTP server using a web page and then contact
the object server through IIOP, the Internet Inter-ORB Protocol.
The client applets run in Netscape or HotJava and contain the
CORBA client communications software as well as the client application
code. The object server can reside on a different machine than
the Web server and is running an IIOP gatekeeper, for instance
on {\sc tcp} port 15000, that is part of the ORB. All further communication
is done through this gatekeeper.
The most important problem we faced was the distinction
between clients and servers, where distributed objects can only
reside on a server. If a client wants to make its objects available
to other programs, it should be configured as a server as well,
with an ORB running on the same host. This causes problems regarding
overhead and licensing and is not a feasible situation for the
distribution of (Java) clients over the Internet.
The same architecture limitation prevents servers from notifying
clients using callbacks.
This feature makes it impossible for clients to pass
distributed object references back to the server, forcing them
to work with other identification mechanisms such as object IDs
or human-readable strings.
Other minor problems we observed concern the lack
of support for existing non-CORBA objects in a distributed environment.
Possible solutions are converting existing classes to CORBA and
making their interface available through IDL, or to write CORBA
object wrappers around these objects.
Finally, not all parts of a CORBA system are compatible among
ORBs at the source-code level.
This problem should, however,
be alleviated with the Portable Object
Adapter (POA).
For giving access to objects within a particular hush
component, we have provided dots (distributed object tables)
for both hush and the widgets components.
Using the dot the client can access an object of a given type by
the name it is given by the server.
The object must already exist in the server.
In case clients are allowed to create objects within
the server, a factory is provided for creating hush
or widget objects.
To allow clients the use of CORBA IDL classes wherever one
of the original hush classes is expected,
client-side adaptors have been provided for each of the hush
or widgets IDL classes.
An additional advantage of client-side adaptors is that
they allow for overcoming the `weaknesses' of IDL with respect to
overloading member functions,
parametrized types and operator definitions.
Typically, client-side adaptors have their corresponding hush class
as a base class and simply delegate method invocations
to the CORBA object they encapsulate.
Nevertheless, in our opinion events should be used in a very restricted manner.
Events tend to break the `crisp' object interfaces that
are one of the benefits of an object-oriented
approach to design.
For the hush CORBA extensions, we have chosen for retaining the original hush
object interfaces.
Note however that the IDL interfaces are somewhat more
abstract than the corresponding C++ interfaces.
Nevertheless, the event interface is part
of the hush module.
Together with the dispatch function of
the handler interface incoming events resulting from user
actions may be dispatched directly to
remote components.
This work
shows how to integrate CORBA functionality
with an already existing framework.
In particular the need for client-side adaptors
for resolving the type clash between the `native' classes
and the CORBA IDL classes has been amply demonstrated.
Enriching hush with CORBA makes crush
a potential competitor of Fresco, the CORBA based GUI toolkit
derived from the Interviews library.
I recommend
(C) Æliens
04/09/2009
Component myths
Component software engineering may be characterized
as an approach that relies on the availability of
reusable `off-the-shelf' components that may be composed
into applications.
This includes applications for banking,
medical services,
corporate management,
entertainment,
etcetera.
Components: myths and reality
Software engineering perspectives
In addition, we need to deal with the practical aspects
of developing component-oriented applications,
that is master the distributed (object) technology involved,
and manage multi-tier architectures.
Standards for interoperability
subsections:
The potential of an object-oriented approach, obviously,
lies in the opportunities for reuse,
both of code and design.
However, reuse requires a common understanding of
the basic principles underlying the technology and its application.
More particularly, the reuse of code requires
(a much more strict)
agreement with respect to the components from which
an application will be constructed and the
language constructs used to implement them.
In this section, we will look at
the object linking and embedding facilities
offered by Microsoft OLE,
and the standardization efforts
undertaken by the OMG (Object Management Group)
directed towards the interoperability of object components.
In addition, we will look at the efforts of the
ODMG (Object Database Management Group)
undertaken to develop a standard for persistent objects.
Object linking and embedding -- COM
Reuse is not necessarily code sharing.
In effect, there seems to be a trend
towards sharing components at a higher level
of granularity, as possibly independent applications.
This approach has, for example, been taken by the
Microsoft object linking and embedding
facility (OLE), which offers support for
embedding (a copy) of a component in a (container)
component, for including a link to another component,
and for storing compound objects.
See slide 11-ole.
Object-enabling technology
Features
Alternatives
Object Request Brokers -- CORBA
The ultimate goal of object technology
may be phrased as the development of
plug-compatible software that allows one
to construct a particular application
from off-the-shelf components.
To achieve this goal, it is necessary to
develop standards with respect to object
interaction and communication interfaces
that support information sharing
between distinct components.
Such standards are developed by
the OMG (the Object Management Group, in
which the leading vendors of software systems
participate, including Digital Equipment Corporation,
Hewlett-Packard Company, HyperDesk Corporation, NCR Corporation,
Object Design Inc. and Sunsoft Inc.).
The OMG aims at defining standards for information
sharing in widely distributed, heterogeneous
(multi-vendor) networks
to support the reusability and portability of
commercially available components,
and more generally, to develop the technology and
guidelines that allow the interoperability of applications.
See slide 11-standards.
Standardization --
Object Management Architecture -- interface standards
Object Services
Future
Persistent objects -- ODMG
In a similar vein as the OMG,
a number of vendors of object database management
systems (including SunSoft,
Object Design, Ontos, Technology, Versant,
Objectivity, Hewlett Packard, POET Software,
Itasca, Intellitic, Digital Equipment Corporation,
Servio, Texas Instruments)
have participated in the ODMG
(Object Database Management systems Group)
to develop a standard for the definition and manipulation
of persistent objects.
The standards proposal of the ODMG encompasses
an object definition language ODL,
which is intended as an extension of the OMG/IDL
standard,
an object manipulation language, OML
and an object query language, OQL,
that provides SQL-like facilities for
the retrieval of information.
The advantage of employing an object database
system over employing a relational database system
is that, in principle, the application programmer
may work within a unified type system,
encompassing both persistent and transient objects.
See slide 11-ODMG.
Persistent objects
Object Definition Language
Object Manipulation Language
Object Query Language
Design principles
Language binding
Discussion
C++ODL/OML binding -- future
Modifications to C++
Standardization efforts -- de facto market share
The Java platform -- technology innovation
Java is the newest wave of technology.
It offers a distributed object-oriented platform
for the development of Web-aware applications.
However, as with any wave of technology,
we must ask ourselves whether it really does provide
an answer to our questions.
And, in the line of Perspectives
Internet applications
Software engineering
Language design
System development
Computer science
IT (in) business
Global village
Discussion
An Internet-based workgroup application
The goal of the project described in this section
was to develop a prototype
for an Internet-based
workgroup architecture using CORBA technology.
CORBA provides a means for developing distributed
object applications,
while the Internet provides a standard and widely accessible network
infrastructure. Users should not need special client software
to use the system, other than a Java-enabled browser such as Netscape.
Discussion
Crush -- extending hush with CORBA
This section describes how the hush toolkit
has been extended with CORBA functionality.
The nickname for this effort was crush.
The major problem that arises when extending
a given toolkit or framework, such as hush,
with CORBA IDL interfaces and classes to
implement these interfaces is to provide for
a seamless integration of the already existing
code with the CORBA-based extensions.
In crush we have included facilities
for object creation and access, as well as client-side
adaptors for the hush CORBA objects,
to resolve the type clash between the original hush
class hierarchy and the hush CORBA object classes.
Extending a framework with CORBA
The legacy problem -- integrating CORBA
Object creation and access
Client-side adaptors
Events versus object method invocation
Interfaces
The hush module
event dispatch( in event data );
};
attribute long type;
attribute long x;
attribute long y;
};
void source(in string file);
void eval(in string command);
string result();
widget root();
};
string path();
void eval( in string cmd );
void configure( in string options );
void pack( in string options );
};
void move( in long x, in long y );
};
Iterators and lists
Object next();
};
long length();
Object first();
Object next();
Object current();
iterator walk();
};
Factories and distributed object tables
hush::kit kit(in string name);
hush::event event(in long type);
};
hush::kit kit(in string name);
hush::container container(in string name);
hush::iterator iterator(in string name);
hush::factory hush(in string name);
};
The widgets module
canvas create( in hush::widget anc, in string path );
hush::item circle( in long x, in long y, in long radius, in string options );
// other items ...
};
interface message : hush::widget {
message create( in hush::widget anc, in string path );
void text(in string txt);
};
interface factory : hush::factory {
widgets::canvas canvas(in string name, in string options);
widgets::message message(in string name, in string options);
};
interface dot : hush::dot {
widgets::canvas canvas(in string name);
widgets::message message(in string name);
widgets::factory widgets(in string name);
};
};
Examples
A remote interpreter kit
Evaluating logical queries
A remote canvas
public:
void plug(widgets::canvas* x) { draw = x; }
int operator()() {
hush::event* e = hush->event(_event->type());
cerr << "Getting event " << e->type() << endl;
e->x(_event->x()+10);
e->y(_event->y()+10);
hush::event::_duplicate(e); // CORBA 2.0
hush::event* res = draw->dispatch(e);
return canvas::operator()();
}
draw_clt(const widget* w, char* path ) : canvas(w,path) {
configure("-background white");
geometry(200,100);
self()->bind(this);
dragging = 0;
}
draw_clt(char* path ) : canvas(path) {
configure("-background white");
geometry(200,100);
self()->bind(this);
dragging = 0;
}
void press( event& ) { dragging = 1; }
void motion( event& e) {
if (dragging) {
self()->circle(e.x(),e.y(),2,"-fill black");
draw->circle(e.x(),e.y(),3,"-fill yellow");
}
}
void release( event& ) { dragging = 0; }
protected:
int dragging;
widgets::canvas* draw;
};
public:
draw_srv( const widget* w, char* path ) : canvas(w,path) {
geometry(200,100);
self()->bind(this);
dragging = 0;
}
void press( event& ) { dragging = 1; }
void motion( event& e) {
if (dragging) circle(e.x(),e.y(),10,"-fill black");
}
void release( event& ) { dragging = 0; }
protected:
int dragging;
};
Moving items
Discussion
Summary
Objects versus components
Standards for interoperability
The Java platform
An Internet-based workgroup application
Crush -- extending hush with CORBA
Questions
Further reading