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