|
February 1997
By Michael Millikin
Network Software
Distributed Objects: A New Model for the Enterprise
Distributed objects help close the gap between corporate networks and the applications that run over them
|
|
Networks are nearly everywhere. CPUs are
cheaper and can churn through more MIPs than ever. So why is it so
tough to distribute processing power across the corpo
rate net? There's
an easy answer: For all the talk about being "network aware," many of
today's apps either can't or don't take the network into account. In
fact, most large organizations still maintain separate development and
networking staffs, each with its own culture.
But the rise of the Internet and the coming boom in intranets is
forcing net managers and application developers to the same
realization: There's got to be a better way to move computing
intelligence around.
There is: the distributed object model (DOM). This paradigm applies
the well-established benefits of object-oriented programming--including
rapid development, reusability, and built-in security--to the
enterprise. In essence, DOM allows objects to interact without knowing
anything about their location. That may sound simple, but it explains
why technologies like Java, Neo, Corba, IIOP, ActiveX, and DCOM
promise to transform not just applications but the network itself.
Corporate networkers whose eyes glaze over m
erely contemplating
that alphabet soup of names and acronyms better get some No-Doz. And
don't think for a minute that object models are something for the
software side to worry about. DOMs could have an enormous impact on
four key areas of networking: processing efficiency, user
administration, net management, and security.
Eventually. When it comes to distributed objects, there's still a
sizable gap between promise and performance. But that's all the more
reason for net managers to master the fundamentals now--before they're
forced to play catch-up.
One of the best-kept secrets of object technology is its essential
simplicity. An object is really nothing more than a small amount of
code that accomplishes a specific task. Objects can be defined that
handle printing, survey desktop resources, issue trouble tickets in
response to alerts, or handle any of a myriad of network chores.
|
MORE INFO
Object Lessons
|
The key here is that objects are atomic (in software-speak, that
means they can't be broken down into smaller pieces). What should
really grab net managers, though, is that they can be treated like
black boxes. It's important to know what an object does, not how it
does it. (For a quick look at some basic concepts, see "
Object Lessons.
")
How does this all play out on the enterprise? Two examples can be
seen in the object-oriented technologies that Cisco Systems Inc. (San
Jose, Calif.) is investigating. First off, the vendor is implementing
intelligent object-agents in its IOS (Internetwork Operating System)
software. The goal is to simplify the management interface of its
internetworking gear and make its boxes more autonomous (thus, less
operator intervention will be required to keep equipment up and
running). (Check out the Manageme
nt Over Java Objects demo on the
Cisco Web site, http://www.cisco.com.)
Second, Cisco and several other vendors are working on a standard
for object-based push technology (also known as publish and
subscribe). This scheme can help eliminate much of the
request-response traffic that can clutter up high-volume distributed
systems. Users or applications register (subscribe) for a certain type
of information that the server then publishes when it receives it. In
a high-transaction environment like a financial system, the
publish-and-subscribe model can greatly reduce network traffic--to the
delight of all.
COPING WITH CORBA
Sun's Java and Microsoft's ActiveX may get most of the media buzz,
but the real place to begin a discussion about DOM is with the Common
Object Request Broker Architecture (Corba) created by the Object
Management Group (OMG).
As its name suggests, an object request broker helps objects find
one another on a network. Corba 2.0, adopted in December 1994, enables
object request brokers from different vendors to work together.
Corba is intended to allow open, extensible communications.
Unfortunately, its level of acceptance so far has been fairly low. As
a result, there's still no widely accepted standard for distributing
objects. Even so, Corba is likely to remain the cornerstone of most
DOM implementations.
Corba's Object Management Architecture (OMA) defines a four-layer
model comprised entirely of objects. Since objects can be known and
manipulated only through their interfaces, the OMG devised an
Interface Definition Language (IDL) that works at all layers. The idea
was that any object whose interface conformed to IDL would be portable
across operating systems, networks, languages, and tools.
STACKING THE DOM
At the bottom of the OMA stack is the ORB itself, which functions
as a kind of "bus" that allows objects to communicate when they are on
a network. The Distributed System Object Model (DSOM) from IBM and Neo
from Sun Microsy
stems Inc. (Mountain View, Calif.) are both
Corba-compliant ORBs. As such, they use the Internet Inter ORB
Protocol (IIOP) for all interobject communications. It's important to
realize that the Distributed Common Object Model (DCOM) from Microsoft
Corp. (Redmond, Wash.) also is an ORB--except that DCOM does not comply
with Corba.
One step up is the object services layer, which makes it possible
to create, name, and manage objects. This is the middleware layer of
the OMA. Corba-compliant ORBs can use the services supplied by
Corba--when they are available (the list is growing slowly).
Alternatively, they can rely on services created with vendor toolkits,
such as Sun's Workshop Neo 1.0.
The common facilities layer furnishes the services used directly by
application objects. Opendoc from Component Integration Laboratories
(Sunnyvale, Calif.) and Object Linking and Embedding (OLE) from
Microsoft live at this layer, although OLE, as part of DCOM, is not
Corba-compliant.
At the top of the OM
A stack are application objects, often called
business objects, since ideally they model business processes. This is
the layer at which Java and ActiveX applets reside.
VENDOR VENUES
|
MORE INFO
The Distributed Future
|
It all sounds straightforward enough, but there are two problems
with this model. First, vendors have very different ideas about where
and how to add value to the standard (witness Microsoft's DCOM and
OLE). Their desire to lock customers in to their own solutions
militates against across-the-board interoperability.
Second, the OMG was ahead of its time (and, in this industry,
getting there first is often worse than arriving late). Corba was
created before the IP revolution really took off. And the resultant
mismatch between the anything-goes Inte
rnet and the painstakingly
devised Corba spec left an opening for Java, ActiveX, and similar
technologies. Ironically, both are stripped-down subsets of Corba that
boast greater flexibility than their predecessor. And both rapidly
overtook Corba in much the same way that TCP/IP outstripped the
complex OSI protocol suite--and for the same reasons.
But the OMG has not been standing still. By mid-1996 it had issued
calls for technologies needed to adapt Corba to the Internet. Most
vendors have responded, with the usual exception of Microsoft. In
fact, Corba developers have created what the OMG calls an "ORBlet"--a
Java applet that, when downloaded into a Java-enabled browser, makes
it possible to communicate with other Corba-compliant objects and
services.
ORBlets are already available from many vendors, including Sun,
Hewlett-Packard Co. (HP, Palo Alto, Calif.), IBM, Iona Technologies
Inc. (Cambridge, Mass.), and Oracle Corp. (Redwood Shores, Calif.).
Eventually Corba support will be built in to
Java browsers,
eliminating the need to download this functionality. What's more,
Corba 2.0--which specifies the interface between proprietary ORBs--will
remain essential to the distributed object model. Without it and IIOP,
competing solutions cannot interoperate.
A JOLT OF JAVA
In a sense, Java is a fortunate accident. Its developers originally
intended it for TV set-top boxes but realized that its small size and
portability made it ideal for the Internet. The rest, as they say, is
history.
Java borrows heavily from Smalltalk in structure and operation and
from C++ in appearance. From the former it gets pure
object-orientation, portability, and simplicity. From the latter it
gets its syntax--while avoiding the kludginess, difficulty, and lack of
security mechanisms that plague C++.
Like Smalltalk, Java is an interpreted language. A Java compiler
does not produce native machine code. Instead, it delivers byte-code
routines that are interpreted by a Java virtual machine--the
software
engine that interprets Java code on each client.
This scheme makes Java one of the most platform-independent
languages, running on everything from embedded systems to (eventually)
IBM mainframes. By enabling applications to execute on any platform,
Java promises to make net management far simpler and less expensive.
Among the vendors that have promised to embed Java in their operating
systems are Apple Computer Inc. (Cupertino, Calif.), HP, Hitachi Ltd.
(Tokyo), IBM, Microsoft, Novell Inc. (Orem, Utah), Santa Cruz
Operation Inc. (SCO, Santa Cruz, Calif.), Silicon Graphics Inc.
(Mountain View, Calif.), and Tandem Computers Inc. (Cupertino,
Calif.).
But it's not all good news. Java apps don't perform or scale as
well as those written in C++. Since Java code must be compiled at
runtime, it's far slower than C++. And the larger the applet, the
greater the performance penalty. On a Web browser Java's
less-than-blistering speed isn't much of a problem. But this model
won't work when develop
ing large, distributed, mission-critical apps
(the last thing net managers need is another drag on response
time).
Help is on the way. Many vendors now offer just-in-time (JIT) Java
compilers for various platforms. These compile incoming applets into
native machine code on the fly. Further, Sun is developing a series of
Java-specific chips; and other silicon foundries are likely to follow
suit. Ultimately, Java applications should run near or at the speed of
those written in C++.
SAFETY FIRST?
For Internet technologies like Java, security is a key concern.
Java's take on the subject can be paraphrased as "I don't care where
the application comes from as long as I know what it can and can't
do." The Java virtual machine implements several restrictions that
keep applets in a so-called sandbox, where they can't access forbidden
system resources. In general, applets loaded from the network can't
read, write, delete, or rename files; listen for or accept network
connections on behalf of t
he local system; invoke programs locally; or
perform other actions that would compromise or damage the local
environment.
But such restrictions come at a price: The verification processes
imposed by the Java virtual machine put another drag on performance.
In addition, this security model takes a sizable bite out of what can
be accomplished with Java applets: File transfers, for instance, are
ruled out.
There is a workaround: virtual machines can be written that relax
these restrictions for local or enterprise applets. To allow this to
be done securely, Java 1.1, released in December of 1996, includes
digital signatures to ensure the authenticity of Java classes and
applets. Given the speed of Internet developments, applets and virtual
machines that implement the new security model should appear early in
1997 (although full-scale deployment will take longer).
In the real world, Java security has proven less than perfect, with
notable holes in regard to IP spoofing and denial-of-service
attacks.
The former has largely been plugged, but there appears to be no
solution for the latter, especially since the root cause is
fundamental weakness in the TCP/IP suite rather than in Java.
STRENGTH IN NUMBERS
Microsoft's ActiveX, based on the vendor's proprietary object
standard, illustrates the strengths and weaknesses of a single-source
solution. Unlike Java, whose biggest assets are portability and
familiarity, ActiveX's advantages stem from the enormous Windows
installed base and the huge number of Windows programmers out there.
ActiveX apps can be written in everything from Visual Basic to C++, or
even in Java. That makes them easy to code and helps guarantee that
they run fast.
ActiveX does not rely on a virtual machine. Instead, it enjoys full
access to all Windows resources and applications--and from there, all
network resources. Thus, ActiveX objects add new capabilities to
Windows on the fly. And since ActiveX applets can do anything a native
Windows application can,
they can be extremely powerful. The catch
here is that ActiveX apps can do anything they want, once they're
loaded. Accepting an ActiveX download could add Superman to a device
or desktop, or unleash his evil twin.
For that reason, Microsoft has been forced to adopt a security
model that can be paraphrased as "I don't care what an applet can do
as long as I know (and trust) where it came from." Like Java 1.1,
ActiveX relies on digital signatures to authenticate the source and
ensure that objects haven't been tampered with.
Despite fundamental differences, Java and ActiveX are similar in
many ways. And the demands of the marketplace are rapidly forcing the
two into peaceful coexistence--complete with similar invocation
methods, scripting languages, security, and database access APIs
(application program interfaces). There also are several schemes to
make Java and ActiveX interoperable, including Microsoft's suggested
modifications to the Java virtual machine that will allow it to be
integrated
with the vendor's COM (Common Object Model). Microsoft also
offers an ActiveX plug-in for browsers from Netscape Communications
Corp. (Mountain View, Calif.).
OUT ON THE NET
|
MESSAGE SERVER
Join the discussion about distributed objects.
|
Digging into the details of distributed object models may keep the
code-heads happy, but net managers are understandably more interested
in how any of this arcana will help with their networks.
For starters, the digital signatures used by Java and ActiveX are
worth a closer look, since they lend themselves to a security scheme
well-suited to corporate intranets: the data vault. This is a two-part
solution: A server acts as an internal vault, functioning as the only
trusted source of A
ctiveX or Java components. Properly configured
firewalls ensure that downloads can only come from the vault.
Once a data vault has been established, it's possible to open the
network to external components on a site-by-site basis--as trust is
established. Eventually, there will be a plethora of security brokers
on the Internet. Verisign Inc. (Mountain View, Calif.), the source of
the ActiveX signing technology, is merely the first of many.
It can't be stressed too strongly: Data vaults are a necessity, not
a luxury, for net managers about to open their enterprises to the
'Net. It's not overly dramatic to view Java and ActiveX apps as
powerful viruses. Both have the power to distribute rogue applications
to end-stations through the network. And despite vendors' attempts to
create workable security models, net managers are justified in being
concerned about all the security aspects of DOM technology.
BOOSTING THE BRAINPOWER
As indicated, distributed objects also can boost the
processing
power of the network by allowing more devices to share the load. It's
important to understand that distributed objects aren't just another
version of database-oriented client-server computing. The latter
typically involves a client application that puts calls to a database
running on a server. Processing is shifted onto the server, which
returns a result to the initiating workstation for display and further
manipulation.
With distributed objects, in contrast, a task can be dynamically
broken down into its constituent components and distributed to
different processors (and processes) across the network, depending
upon their abilities and their availability. In effect, the network
itself puts a task up for bid; processors that can handle the specific
chores and are free to take on the job respond. Eventually,
functionality will migrate from "client" to "server" and back again as
latency and processing loads dictate.
Building and implementing this sort of distributed model means
taking
both the network and the application into consideration. Thus,
it demands close cooperation from both sides of the MIS house.
Applications that are written without considering the impact on the
network are doomed to fail on the enterprise. And net managers who
can't see beyond bits and bytes and data pipes could well become
victims of their own shortsightedness.
UPGRADE AUTOPILOT
Distributed objects also can take some of the sweat equity out of
upgrading client software and tracking licenses--two of the most
onerous burdens on net managers. Java, for instance, can make it
possible to upgrade applications automatically, when end-users first
log onto the network (another use of the publish-and-subscribe model).
Simply said, an object on the desktop will check the server as soon
as the sign-on is complete to see if any upgrades have been loaded. If
it finds one (or more) it pulls the appropriate code from the server
and installs it on the workstation--before the application actually
l
oads. Thus, upgrades become ongoing, automatic, and incremental. And
corporate networkers who aren't wasting cycles on low-level
administrative tasks are free to concentrate on more important
matters, like making sure their nets are efficient and cost-effective.
At that point, DOM becomes a strategic tool for helping companies
maintain healthy competitive advantages.
WASTE NOT, WANT NOT
Another advantage to DOM is that it helps conserve network
bandwidth--particularly when applied to net management. Today, much of
the intelligence of a net management system is centralized. Managed
devices transmit status reports back to a central console for
processing. On a WAN, this wastes expensive bandwidth. On a LAN, it
clogs the network with alerts, traps, responses, and other
messages.
DOM, in contrast, migrates more intelligence into managed devices.
Switching hubs, for instance, will become increasingly autonomous. Net
managers will load them with powerful net management applications
(compos
ed of diverse objects) so that they can set bandwidth
parameters dynamically, in response to local conditions.
Back at the management console, queries will become increasingly
general--and thus sparing of network bandwidth--while returned
information will be increasingly specific. Distributed object-agents,
for example, will rely on their inherent intelligence to respond in
detail to the simple message "report status." This ability stems from
a key concept of distributed object programming--polymorphism. It may
sound like a mouthful but all it means is that objects are written to
respond to the same message in different, though appropriate, ways.
Thus, an object agent in a switching hub will deliver one answer to
the message "report status," while an agent in a modem will deliver
another, equally correct, response.
Management requests will thus be narrowed to individual classes and
subclasses of network equipment--right down to vendor-specific
information. And with properly configured firewalls,
vendors will even
be able to perform remote updates, maintenance, and troubleshooting of
equipment at customers' sites.
|
FIGURE 1
The Object of the Network
|
Consider, for a minute, what a distributed object network might
actually look like (see
Figure 1
). For starters, processing will
migrate throughout the system in response to changing loads.
Subsidiary servers may act as workgroup object caches and applications
servers to conserve bandwidth on the corporate backbone and reduce the
load on the corporate data vault. Meanwhile, subsidiary net management
processors may control remote network devices autonomously, using
economic models downloaded as objects.
Of course, net managers know that when anything sounds this good
there's got to be a
catch. There is. It's going to take a long time to
come to any agreement about how, for example, to support SNMP with
object-oriented management APIs such as the Java Management API
(J-MAPI). This isn't just a technology issue: Vendors eager to push
their own solutions are dividing the industry into camps instead of
fostering cooperation. But the strength of Corba is its ability to
solve interoperability problems by encompassing them; as in the TCP/IP
world, the rule is "if an agreement can't be reached, add another
service."
THE SWITCH IS ON
Corporate networkers considering a move to switched nets and
virtual LANs (VLANs) will be happy to know that both schemes are a
great fit with distributed objects. One of the key concepts of DOM is
keeping processing power and intelligence as close as possible to
where the work is done. That's where switches and VLANs come in. Both
make it possible to establish logical subnets, effectively segmenting
the network and making sure bandwidth isn't wasted de
livering messages
where they're not needed. Similarly, distributed objects and their
attendant messages can be restricted to specific subnets, boosting
efficiency even further.
Switching also helps address a regrettable weakness in the TCP/IP
suite: the statelessness of HTTP (hypertext transport protocol), which
simply means that it can't look after the links it sets up and tears
down. This is fine on the Internet--a global network for distributing
data--but complicates things greatly in the world of DOMs. Objects do
best in a stateful environment, but distributing them using Netscape's
Javascript (or similar methods) means setting up and tearing down
multiple HTTP circuits, consuming considerable bandwidth along the
way. By eliminating shared-access networks and directing traffic to
specific destinations, switching can greatly reduce bandwidth
crunches.
NETWORKING THE COMPUTER?
One of the greatest strengths of distributed objects is their
ability to dynamically deliver only the func
tions needed. That's the
basic idea behind the network computer championed by Oracle, IBM, and
Sun.
The early thinking about the network computer (a.k.a. Internet
cruiser) is that barebones clients at the desktop will dramatically
reduce the cost of application development, deployment, and
administration. Trouble is, even if the network computer manages to
fulfill these promises, it will, over time, more and more come to
resemble the PC it was meant to supplant. And as that happens,
management costs will start to spiral upward.
Why? In a nutshell, objects need to be cached locally to improve
performance because bandwidth doesn't increase as fast as CPU
performance. Although object programs will tend to be much smaller
than present-day procedural applications, continual consumption of
network bandwidth isn't a good idea. The most efficient way of dealing
with objects is to cache them locally, in exactly the same way that
Web pages are cached to improve performance.
Thus, one of the task
s facing designers of Java-enabled networks
will be to determine the size of such caches, the medium used, and the
objects' expiration dates (which will depend on the frequency that
components are updated). (ActiveX includes built-in mechanisms to
handle this.) RAM, flash memory, or hard disk are the typical choices
for a cache--the last being by far the most cost-effective. But a
network computer with a hard drive is--surprise!--a PC. And all those
cache decisions mean more work for net managers.
It gets even more complicated. Highly autonomous objects can
themselves be security risks if they're coded with sensitive,
mission-critical data. (That's one of the reasons they're best kept
close to home.) Security concerns, then, become one of the critical
considerations in setting cache expiration times. Remember what
polymorphism makes possible: Each object can have its own method of
responding to a "drop dead" message. Critical business objects that
must be on the desktop can expire daily--or even with
each use. But
corporate networkers who need this level of protection are going to
have to trade off bandwidth to get it.
OUTSOURCED OBJECTS
Finally, distributed objects will have an effect on the way
outsourcing is handled in the industry. Each DOM--Neo, DSOM, DCOM,
Corba, and others not yet invented--will have an entire culture of
resellers and integrators gathered around it. These object outsourcers
will have the expertise needed to fit together whatever mix of
features and functions is needed. Of course, this scenario is still
decidedly future tense. But now's the time to start identifying the
resellers and integrators that can help net managers implement the
best technology for network design, operation, and management.
Michael Millikin is senior vice president of Interop, a division of Softbank Expos (Foster City, Calif.).
[
Home
]
[
Registration
|
Subscriptions
]
[
Contact Us
|
E-Mail
]
|
|
|
 |
|
|
