Demystifying Distributed Computing

In distributed computing, the
processing of an application is divided between two or more com- puter systems connected
over a network. The systems involved may be instances of the same platform or may
represent heterogeneous platforms. Distributed computing allows an organization to take
advantage of the strengths of different computing platforms and to share information
broadly across the enterprise. Distributed systems occasionally are built, more frequently
bought, by corporate computing organizations. There are many forms of distributed
computing.

Today, the most widely used form is
client server, where an application client running on an end-user programmable computing
device (typically a PC) accesses one or more servers that provide application logic or
data management functions as part of a distributed application. A primary challenge when
designing an application that executes and stores data on two or more platforms is the
creation of a uniform scheme for passing information among the various program modules.
This scheme, called middleware- a catchall term for software that ‘sits in the
middle’-provides connectivity between different parts of an application. The major types
of middleware include remote procedure calls, message-oriented middleware, distributed
objects and transaction processing monitors. The use of software components based on
object technology is becoming an accepted technology for the implementation of distributed
computing.

Distributed objects are particularly
well suited to this task because the object paradigm simplifies the job of distributing
application functionality across multiple platforms.It also allows application developers
to take advantage of object-enabling services provided by operating system, database and
other software vendors. The Object Management Group, representing a broad cross-section of
the information technology industry, has developed Common Object Request Broker
Architecture standards that allow software components to be implemented using multiple
programming languages and on different computing platforms.

Microsoft’s competing technology for
distributed objects, Distributed COM, is a distributed – computing generalization of the
company’s original Component Object Model technology and takes advantage of a set of
services Microsoft is building into Windows NT. Sun’s Java language and run-time
environment, which are used widely in internet computing, have been extended with the
JaveBeans component framework. JavaBeans components provide execution portability because
they can be run on any platform with a suitable Java run-time environment.The Enterprise
JavaBeans specifications define a set of enterprise services that allow server-side Java
execution.

Middleware

Middleware is a term used to
describe several different types of software, all of which share the common characteristic
that they sit in the middle and provide connectivity between different parts of an
application. A major challenge in building distributed applications is the creation of a
uniform scheme for passing information between program modules and accessing data from
multiple sources, with program and data both possibly residing on heterogeneous platforms.
Middleware provides developers with a uniform interface through which their programs can
access other applications. Each application needs to interact only with the middleware.

The middleware software then
performs the necessary translations to communicate with the respective databases,
operating systems and applications. In this sense, middleware presents the application
developer with a single, consistent interface, the illusion of single underlying server
that masks the complexity of the actual computing infrastructure. In addition to providing
connectivity, middleware typically is used to provide specialized services that
applications can call on, where it is desirable to isolate those services rather than
building them directly into an application. They will either be used by multiple
applications, thus making it more efficient to provide a service all applications can
share, or because software to implement those services can be purchased from a middleware
vendor rather than being developed in-house. Different types of middleware implement
different services. Some of the major types of middleware in use today are as:

DATABASE ACCESS AND DISTRIBUTED
DATABASE MIDDLEWARE: Provides access to multiple heterogeneous databases that may reside
on multiple computer systems. In some cases, the middleware is used to provides a uniform
application programming interface (API) to multiple data sources, thus freeing the
application developer from having to design the application to access a particular
database; the most common example of this approach is Microsoft’s ODBC. In other cases,
the middleware implements the connectivity that allows an application to access databases
on remote systems.

TRANSACTION PROCESSING MIDDLEWARE:
Provides transactional integrity where an application will be updating multiple databases.
This functionality typically is also available from database vendors as part of their
server products, but a separate TP monitor would be required when multiple databases from
different vendors are being updated by a single application. A TP monitor also can be used
to improve performance for high-volume applications by managing a pool of threads on the
database server to which application clients can connect, thus avoiding the overhead of
creating a new thread for each client connection.

REMOTE PROCEDURE CALLS: Remote
Procedure Calls (RPCs) allow an application running on one computer system to call a
procedure that executes on another system. The RPC middleware provides an API the
programmer uses to initiate and respond to the procedure call in the client and server
applications. Then at run time, it manages the details of transferring the calls across
the network.

MESSAGE-ORIENTED MIDDLEWARE:
Message-Oriented Middleware (MOM) provides inter application communication, typically on
an asynchronous basis. The MOM software provides an API the programmer uses to create and
accept messages in the client and server applications; then at run time, it manages the
details of ensuring reliable delivery as the messages are transferred between the systems.

DISTRIBUTED OBJECT MIDDLEWARE:
Extends the basic model of object-oriented programming, where self-contained objects send
messages to each other to invoke services, by allowing objects to be used across a network
of distributed systems. Many types of middleware were originally designed for
inter-application communication on a single computer, rather than for a network of
distributed systems. Database access/distributed database middleware, TP monitors, and MOM
all had their origins in centralized computing environments and have been extended for use
in distributed computing. Other middleware types, such as RPCs and distributed object
middleware are unique to distributed systems because they have been designed specifically
to extend a single-system programming model, procedure calls and objects respectively, to
the distributed environment.

The latest evolution in distributed
computing has been the trend toward object-oriented design techniques and the concept of
distributed objects. Distributed objects create a new design for the middleware
environment. Object middleware standardizes the interfaces published by objects so they
appear and act the same whether the object encapsulates data access to a database,
information stored in a legacy file system on a mainframe or minicomputer, or distributed
data from many sources made available via an application server. Distributed object
middleware allows the objects to be both local or remote. Distributed object middleware
offers the potential of ‘objects everywhere’ by providing standardized techniques for
finding objects, handling security issues, and invoking services from remote objects
transparently over the network. Middleware primarily is of interest to organizations
developing custom applications or to software vendors designing applications to work with
third-party middleware.Organizations that buy rather than build applications typically
will rely on the distributed computing capabilities of the products they purchase.

Need for distributed objects

The promise offered by using
software components and distributed objects is that developers can assemble business
applications from collections of these objects and deploy them more quickly than
developing applications using more conventional techniques. These software components
generally consist of products purchased from vendors. The savings in development time
comes from the use of these pre-engineered components. Basing development on components
also can deliver some level of interoperability. Potentially, these objects can exist
anywhere on the local network, the local intranet, or the entire internet because object
middleware includes the flexibility needed to support heterogeneous environments. A goal
of some of these technologies-CORBA in particular-also is to provide a uniform
component-based wrapper for existing non-object code.

Making robust and important legacy
code available as software components preserves the existing investment in this software
and allows distributed computing to encompass applications. Furthermore, component-based
development offers the potential to change and customize applications more easily by
adding or modifying components. Some of this modification can be accomplished dynamically
by adding new or more powerful components. Therefore, companies with these needs
increasingly are looking to distributed objects to allow global access to information
resources while hiding platform and database heterogeneity. A method gaining increasing
popularity in this context is the use of Object Request Brokers (ORBs) that act as a
generic middleware layer for connecting distributed software components.These products
allow software components to interact across networks by locating the appropriate objects
and brokering the communications.

CORBA and ORBs

For heterogeneous components to work
together successfully across the enterprise, guidelines must be adopted for how component
interfaces are defined and components are invoked. In late 1989, a group of vendors formed
Object Management Group (OMG) to craft a set of standards for distributed computing with
components. OMG now has more than 800 members, spanning the gamut of the computer
industry. During the last eight years, OMG has been actively soliciting proposals from
vendors for the development of architecture and a series of detailed specifications for
CORBA. Although some vendors are involved in developing the CORBA standards (SAP and
Microsoft, for example), they still are using their own proprietary technology within
their products and are unlikely to change anytime soon. CORBA represents the most
ambitious middleware project undertaken by the computer industry. OMG has focused its
energy on developing an object management architecture that provides CORBA core services
and elements, CORBA facilities, and CORBA domains.

The CORBA core includes standardized
network communication protocols, interface mappings for various languages,
interoperability, interface and implementation repositories, and calling conventions
implemented by a CORBA ORB. The CORBA 2.2 specification was released in March 1998. Work
is going on for developing specifications for several additional CORBA facilities and
services. The CORBA model uses ORBs to handle requests from programs to components and
from components to each other. An ORB is the middleware that establishes the client-server
relationship between objects. Using an ORB, a client can invoke the method of a server
object transparently. This server object, so-called because it handles requests from the
client object, can be on the same machine as the client object or across the network. The
ORB intercepts the call and is responsible for finding an object that can implement the
request, passing data, invoking the requested operation, and returning the results. To
enable these functions, CORBA defines a standard way for components to specify their
interfaces, including the kind of data they expect to be passed and the kind they expect
to return. The standard way of defining object interfaces is via the CORBA Interface
Definition Language (IDL), the syntax of which looks similar to C++, IDL has been adopted
by ISO as an international standard. CORBA 2.2 currently defines standard IDL mappings for
several programming languages. These IDL mappings provide cross-language portability and
allow creation of CORBA objects that provide the same behavior using any of these
languages. This feature also enables encapsulating legacy code in a function to make this
existing investment available as reusable objects. This encapsulation often is called a
wrapper.

Internet inter-ORB protocol

Internet Inter-ORB Protocol (IIOP),
introduced with the CORBA 2.0 specification in 1996, is a key component of the CORBA
environment. It solves the problem of how ORBs from different vendors communicate with
each other. Prior to CORBA 2.0, OMG began designing a protocol for inter-ORB
communication. This protocol came to be known as the General Inter-ORB Protocol (GIOP). It
specified the format of seven key data messages that ORBs would need to share data, and it
detailed how data should be sent between ORBs. The first implementation of the GIOP
specification became IIOP, which is a slightly modified version that uses TCP as a network
transport. IIOP was designed specifically to ensure all ORBs support at least one common
network communications protocol.

The CORBA documents also allow for
special inter-ORB protocols for environments that have specific needs not handled
optimally by IIOP- or GIOP-style protocols. Examples of these Environment-Specific
Inter-ORB Protocols (ESIOPs) are found in the BEA ObjectBroker ORB, and use protocols
originally developed for DCE.

Component object model

Microsoft has been promoting its own
alternative to CORBA for a distributed software component architecture. The Microsoft
approach is based on Microsoft’s. Component Object Model (COM), which evolved from an
earlier mechanism known as Dynamic Data Exchange (DDE) to provide interprocess
communication between desktop Windows applications. COM began as Microsoft’s OLE
technology, introduced in 1990 with Windows 3.0, OLE originally implemented linking
information between applications and the ability to embed a data object from one
application in a document created by another application. OLE also supported the notion of
compound documents composed of document components created in several applications.

The initial version of OLE, later
defined as OLE 1, used DDE messages for interprocess communication between clients and
servers. COM later was enhanced to take advantage of multithreading on Windows 95 and
Windows NT. DCOM, the distributed version of COM, was first introduced on Windows NT for
accessing remote COM objects across a network. DCOM later was made available on Windows 95
as an add-on software. DCOM was based conceptually on the DCE RPC mechanism with
proprietary Microsoft extensions that prevent interoperability with existing DCE
implementations. During the evolution of this technology, Microsoft renamed OLE components
known as controls, generally visual elements of an interface, to ActiveX. ActiveX
technology now includes documents in addition to controls. Microsoft has been adding
services to COM, such as MTS for managing transactions and MSMQ for enabling asynchronous
messaging.

These services are included with
Windows NT Server Enterprise Edition. These services also were made available as part of
an option pack, a separate CD ROM sold as optional software, for use on Windows NT Server
and to a limited extent on Windows NT Workstation and Windows 95. Microsoft also has
announced the upcoming release of COM+, a set of extensions to COM. Like the challenge of
developing CORBA applications, writing distributed programs using COM is a complex task
for developers. A substantial amount of complicated boiler plate code must be written that
has nothing to do with the actual task at hand. COM programming also has been complicated
by the fact that many tools and languages support only a subset of COM features.

The COM+ architecture essentially
moves parts of COM programming and COM extended services (MTS and MSMQ) into the operating
system as COM+ run-time services. After these COM+ services become incorporated in the
operating system, new development tools will simplify COM programming for developers. Some
of these COM+ extensions will become available with the introduction of Windows NT 5.0 in
1999, while other features, additional platform support, and COM+ development tools will
be introduced farther in the future.

The COM model

COM principally provides the
architectural abstraction for OLE components. COM was based on several fundamental
concepts: an Application Binary Interface (ABI) for calling functions, a provision for
grouping functions into interfaces, and a base interface. COM defined a standard for
laying out virtual function tables (vtables) in memory and a standard for calling
functions through these vtables. Any computer language that implements calling functions
through pointers-Ada, BASIC, C, C++, Pascal and Smalltalk, for example-could be used to
write OLE components and could interoperate. Like CORBA, a COM component is not an object
in the strict object-oriented sense. A COM component, sometimes referred to as a COM
object, has a different meaning than an object as defined in C++ or Java. In COM, a
component represents a block of executable code that provides some service or services to
the rest of the system.

A COM component supports a base
interface along with a collection of other interfaces needed for the task. COM components
usually also contain some associated data fields, but these data elements are hidden
(encapsulated) completely from other COM components. The only way to access other COM
components and retrieve private data is through interface pointers and by calling
interface functions indirectly. This indirection through pointers allowed COM simply to
substitute RPC proxies and stubs for these pointers and call COM functions located on a
remote machine, the evolution to DCOM. COM is language-neutral, and support for it is
included with Microsoft C++, Visual Basic, and Visual J++ development tools. Access to COM
in C/C++ also is available using several other C/C++ development tools for Windows 3.x and
Win32.

For example Inprise’s Borland C/C++,
Sybase’s Optima++ and Powersoft development suites, Symantec’s C/C++, and Watcom’s C/C++.
Other language support for COM is provided in Pascal by Inprise’s Delphi and in COBOL by
Fujitsu and Micro Focus. Microsoft has defined a collection of standard COM interfaces for
implementing some standard facilities, including persistence (structured storage),
monitors (associating a name with a COM object), and dynamic dispatch (invoking methods
dynamically). COM automation allows applications such as Microsoft Internet Explorer,
Microsoft Office, and development tools such as Visual Basic to export COM components and
access COM components provided by other applications.

Multithreading and distributed
COM

For efficiency and to provide
scaling when used on Windows NT multiprocessor machines, Windows 95 and 98 do not support
the use of multiprocessors, COM objects need the ability to use multiple threads of
execution. The transition to using Win32 multithreading under COM has been difficult for
developers. Microsoft defines the basic element for thread safety in COM as an apartment-a
group of one or more threads in a process that can execute method calls. Two different
types of apartments and several different threading models have been defined by Microsoft.
A Single-Threaded Apartment (STA) allows only a single thread to execute per apartment.
The motivation for STA was to synchronize and serialize access to methods on a thread for
legacy COM applications so they would continue to function properly when executed on
32-bit Windows environment supporting multithreading. Without this, legacy COM
applications that were not written to be thread-safe could fail.

A Multithreaded Apartment (MTA)
allows more than one thread executing per apartment. When using MTA, a COM application
explicitly must provide its own synchronization for thread safety by using various Win32
synchronization APIs. Microsoft defined four different threading models to represent
whether a single STA or multiple STAs are supported and whether an MTA is supported. Not
all platforms support these threading models. Windows 3.x supports only the STA models.
Unix ports of COM/DCOM support only MTA models because STA depends on the existence of
Windows message queues, which are unavailable on Unix. On Win32, multiplicity of threading
models and the complexity of developing and properly testing MTA-based applications for
thread safety caused problems for developers.

As in any multiuser, multithreaded
environment, proper thread synchronization is difficult to test because of the
intermittent nature and non-repeatability of the problem. Because DCOM used a proprietary
implementation of the DCE RPC for its component architecture, COM/DCOM essentially is
limited to use within a Microsoft-only environment. Microsoft implemented support for COM
on the Macintosh for use by Microsoft Office and other applications. With the exception of
Software AG’s EntireX DCOM on Solaris mentioned previously, no DCOM support for Unix is
available as of mid-1998. A stumbling block in distributed computing is the lack of
interoperability between COM/DCOM objects and CORBA components. Getting these two
component models to communicate has proven difficult. The BEA ObjectBroker has an
extension that allows desktop OLE/COM clients to communicate with CORBA servers. OLE
messages are mapped to ORB messages. This capability is based on technology licensed from
Visual Edge Software. This technology, called Object Bridge, is available directly from
Visual Edge Software and is the only product to provide complete bi-directional
communication between CORBA and COM. Specifically, it allows CORBA to interoperate with
COM and with OLE automation.

In mid-1998, Iona Technologies
released an evaluation version of OrbixCOMet Desktop. The first product in the OrbixCOMet
product family, it provides bi-directional communication between COM and CORBA for clients
on the Win32 desktop. Most other packages currently available simply allow CORBA-to-OLE
automation interoperability. The difference is that OLE automation requires use of CORBA’s
dynamic invocation function, which is significantly slower than the more common static
invocation method used among CORBA components. The COM/CORBA gateway, or bridge, approach
has some shortcoming. Because gateways require translation of requests in place of direct
requests, performance is reduced. Gateways also usually have some limitations because the
mapping between two sets of services prevents a complete utilization of some features.

COM+ and active server

Microsoft recently announced the
upcoming release of the Component Object Model+ (COM+) services. These COM+ extensions
bundle into the operating system a uniform set of COM+ run-time capabilities and services
to simplify development. Microsoft has begun beta testing some COM+ features as part of
early Windows NT 5.0 beta releases. Windows NT 5.0 is not expected until mid-to-late 1999,
and the use of these COM+ features will be dependent on the availability of new
development tools that support the features. At present, COM+ should be considered a
concept under development for the future direction of COM. The primary goal of COM+ is to
make it easier to write COM components and distributed applications. COM+ is slated to
provide additional facilities in the COM/DCOM infrastructure and support for future
development tools.

The new COM+ run-time services will
be designed to provide more uniform security and memory management as well as a
data-binding feature that allows binding between object fields and specific database
fields. COM+ enables components to redirect their requests dynamically by calling various
services at run-time rather than being bound to a single implementation of a service. The
COM+ run-time will include the MTS and MSMQ components. COM+ also further defines the
concept of a package that consists of a collection of COM components and programs that
should be grouped together conceptually during run time and installation. A future COM+
administration tool is supposed to simplify the deployment of these COM+ packages on
client machines.These new COM+ run-time features are designed to be language-neutral.

However, the availability of future
tools for COM+ development will determine whether COM+ can deliver on the promise of
language neutrality. Judging by past experience, COM+ will be supported first by Microsoft
C++, Microsoft Visual J++, and Microsoft Visual Basic. Later support will come from the
major C++ desktop tool vendors after they determine the language extensions that Microsoft
has made to the language to support COM+. Tools support in other languages will be less
common and slower to arrive. The COM+ run-time is to provide new functions similar to the
naming, security, persistence, and versioning services found in CORBA.

For directory services, DCOM will
rely on Active Directory, a new distributed directory service that runs on Windows NT
Server 5.0. Active Directory will require service patches to run on Windows 95, Windows
98, and Windows NT 4.0. It essentially is a combination of the Domain Naming System (DNS)
and Lightweight Directory Access Protocol (LDAP) using Microsoft APIs. COM+, in
conjunction with MTS and the underlying COM/DCOM architecture, will form part of
Microsoft’s Active Server, an assembly of server-class capabilities delivering transaction
and messaging services to any COM component, including Java applets. Active Server is an
extension to the Microsoft Internet Information Server (IIS) that allows web clients to
communicate with COM components and participate in transactions managed by MTS. Extensions
to Microsoft’s Internet Server API (ISAPI) allow the web server to execute JavaScript or
Microsoft VBScripts on the Windows NT host machine.

Java-based component architecture

Java applets and full applications
are suited to the notion of component-based development and distributed computing. The
Java language is an excellent match for component-based development with its
object-oriented features and shorter learning curve compared with C++. Distributed
computing offers the promise of assembling sophisticated applications from distributed
objects. Java applications offer the further promise of allowing these applications to be
moved easily across platforms for execution, as long as a Java Virtual Machine (JVM)
exists on the target platform. JavaBeans is a specification for components that can be
deployed on any Java platform. JavaBeans extends Java’s cross-platform ‘write-once,
run-anywhere’ capability to the development of enterprise-class distributed applications
with the features of component reusability.

Like Java applets, JavaBeans
components can be used to give web pages or other applications interactive capabilities
such as computing interest rates or varying page content based on user or browser
characteristics.The Java-based component model has followed a slightly different
evolutionary path than Microsoft’s DCOM, although both had their foundations in
client-side GUI component development. The Java model did not emerge from an RPC-based
model that grew to include distributed computing and object interoperation. Instead, the
JVM concept and associated Java programming language created an environment where applets
could be written, fetched across the internet, and run anywhere.

As the applet concept grew and Java
began to take hold as a cross-platform development language, JavaSoft (a division of Sun)
sought to extend Java with a component model by providing JavaBeans as a components
definition. In essence, JavaBeans is a component specification for the Java language.
Initially intended for the Sun-originated Java and aimed at NEO, JavaBeans has developed
greater compliance to CORBA standards and broadened its interface capability to become a
true, standalone component framework. The actual component architecture model is a
collection of facilities from SunSoft and JavaSoft, both divisions of Sun, the key to
which is Java. The collective component model includes Java, Java-based APIs, and
JavaBeans.

Fundamental to a working Java-based
component architecture model are the Java-based APIs that provide the operating services
on top of the Java language environment.

JavaBeans

A Bean is a specialized, primarily
visual component that can be added to any application during development and cam be
manipulated by the Java builder tool. It can range from a small visual control such as a
program status indicator to utilities such as a word-processing component in a larger
application. JavaBeans do not differ much from other components, except for their
requirement of a Java implementation. Beans can be combined and inter-related to build
Java applets or applications and as such must be executed within a larger application, the
hosting application is called a container.

Beans also can be used to create
new, more comprehensive, or specialized Beans. The properties of a Bean are attributes,
which describe the state of the Bean, such as color, position, and title, and methods,
which are the actual functions to be performed by the Bean. For example, Bean methods can
manipulate a Bean’s internal state, interact externally with other objects, and respond to
events-actions performed when special internal or external signals occur, such as a mouse
click. In addition, Beans can implement conceptual and non-visual objects such as business
rules. Bean features are made known to development tools through a process known as
introspection, which analyzes the Bean at design time or run time to determine the
properties, methods, or events the Bean supports. BeanInfo classes provide advanced
control over a Bean’s features.A separate introspector class is used by the builder tools
to analyze the design of a Bean and its associated BeanInfo. To build a JavaBeans
component, Java programs include statements that describe component properties such as
user interface characteristics and events that trigger a Bean to communicate with other
Beans in the same container or elsewhere on the network.

When a Bean is in use, its
properties-for example, the background color of a windows-are visible to other Beans. In
this way, Beans that have not ‘met’ before can learn each other’s properties dynamically
and interact accordingly. Beans also have persistence, which is a mechanism for storing
the state of a component to disk. This capability would allow, for example, a Bean to
remember data that a particular user had entered during an earlier user session.

Enterprise JavaBeans

Enterprise JavaBeans (EJBs) are
specialized, non-visual JavaBeans that run on servers. EJBs extend JavaBeans from its
origins as a client-side GUI component set to a server-side component model. The EJB
specification defines a component model to support multitier, distributed object
applications. EJBs provide hooks for enterprise-class application developers to build
reusable software components that can be combine to create full-applications. The hooks
include interfaces to development environments and richer class libraries geared toward
the enterprise. Server components execute within a component execution system (called an
Enterprise JavaBeans Container), which provides a set of run-time services for the server
components, such as threading, transactions, state management, and resource sharing.

The need for a component execution
system means that EJBs do not need the standard JavaBeans container context to execute.
The EJB model defines the interrelationship between an Enterprise JavaBean component and
an Enterprise JavaBean container system. Any Enterprise JavaBean can run in any Java
run-time environment that supports the EJB server specification. At minimum, the EJB
server must provide a container for Enterprise JavaBeans (the EJB Container). The EJB
Container implements the management and control services for a Class of EJB. The EJB model
supports implicit transactions.

To participate in distributed
transactions, individuals EJBs do not need special code to distinguish individual
transactions, and their operations. The EJB execution environment automatically manages
the start, commit, and rollback of transactions on behalf of the EJBs. Transaction
policies can be defined during the installation and configuration of the EJB application.
Optionally, transactions can be controlled by the client application. JavaBeans and the
other Java Enterprise APIs are all part of JavaSoft’s Java Platform for the Enterprise,
involving the extension of Java beyond the desktop to network and application servers.
Enabling Java on the server allows for development of Java applications and JavaBeans that
can be deployed on either a desktop or a server, extending the ‘write-once, run-anywhere’
goal for the Java platform.

The final version of the EJB 1.0
specification was released by JavaSoft in December 1997, although product support for EJB
from Java vendors began well before this date. The EJB model plays a pivotal role in the
Enterprise Java Platform. The EJB environment defines a series of services that are
provided to enterprise application components. The Enterprise Java Platform implements an
extended API set geared to support enterprise-level transactions, and it provides a common
interface to a variety of system services such as naming, directory, messaging,
management, interprocess communication, database, and transaction. These enterprise APIs
leverage existing Java APIs such as Java Database Connectivity (JDBC), the Java Remote
Method Invocation (JRMI), and the Java Interface Definition Language (JIDL) plus the Java
Naming the Directory Interface (JNDI).

The extended features include the
Core Reflection API, a low-level collection of classes that supports the introspection
mechanism; the Object Serialization API for maintaining object persistence that also
implements improvements in the Java Event Model; and the Java Foundation Classes based on
the Abstract Windowing Tookit (AWT). EJBs are based on version 1.1 of the Java Development
Kit (JDK 1.1). The JDK provides an event model-a mechanism that objects use to interact
dynamically in response to external or internal conditions-with different classes for
varying events and event sources and listeners. The EJB model utilizes the Java security
services supported in the JDK. A major enhancement in JDK 1.1 compared with previous
versions is the addition of database access classes in the form of JDBC APIs.

With EJB published and tested,
vendors of Java frameworks are beginning to move their products to EJB. The most prominent
of these is IBM’s San Francisco Project, which is a collection of business objects that
the company expects to move to EJB during 1999. JDBC, Java IDL, JNDI, JMS, JTA, JTS and
RMI are all API’s that, coupled with JavaBeans, form a middleware framework of which Beans
are the components and Java the defining language. Table describes the products and APIs
for building enterprise applications.

COM and Java

Due to the popularity of the Java
language, particularly in developing internet/intranet applications and services,
Microsoft has embraced Java but has made it platform-dependent. However, the Java language
is the only aspect of Java that Microsoft is embracing because the remaining elements of
the Java environment-such as Sun’s impelementation of the JVM, JavaBeans, Enterprise
JavaBeans, and many Java system APIs-are viewed by Microsoft as direct competition to its
operating systems. Microsoft does not include Sun’s Java Foundation Classes (JFC) in its
implementation of Java, replacing them instead with its own Windows Foundation Class (WFC)
libraries. Solely available on Microsoft Windows 95/98 and NT. WFC is a set of classes for
Graphical User Interface (GUI) development that communicates directly with the underlying
Windows APIs. Prior to the introduction of WFC in mid-1998, Microsoft promoted the use of
its earlier Application Foundation Class (AFC) libraries for Java GUI development. AFC was
favored instead of the standard Abstract Windowing Toolkit (AWT) that is supported on all
Java environments. Like WFC, AFC was usable only on the Windows operating system.

With the introduction of WFC, AFC
has been deemphasized and is being phased out. An additional facility to tie Java
applications more tightly to the Windows environments J/Direct, a feature within
Microsoft’s implementation of the JVM that supports direct calls to the entire set of
Win32 APIs. With J/Direct, developers can write Java applications that depend on Win32
DLIs without using native Java methods, thereby removing the ‘run-anywhere’ aspect of the
Java promise. Microsoft Visual J++ and the Microsoft JVM provide tools to make it easy to
support COM from Java. The JActiveX tool makes it simple to build COM objects in Java and
communicate with other COM objects from Java. This tool places special comments in the
Java source code that are converted to Java class file attributes to support COM features.

Excerpted with premission from
Technology Forecast 1999 by PriceWaterhouse Coopers

Leave a Reply

Your email address will not be published. Required fields are marked *