Electrical computers and digital processing systems: multicomput – Distributed data processing – Client/server
Reexamination Certificate
1999-09-23
2002-05-07
Luu, Le Hien (Department: 2152)
Electrical computers and digital processing systems: multicomput
Distributed data processing
Client/server
C709S201000, C709S238000
Reexamination Certificate
active
06385643
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to distributed processing systems and, in particular, computer software in distributed processing systems.
BACKGROUND OF THE INVENTION
There are several types of distributed processing systems. Generally, a distributed processing system includes a plurality of processing devices, such as two computers coupled to a communication medium. Communication mediums may include wired mediums, wireless mediums, or combinations thereof, such as an Ethernet local area network or a cellular network. In a distributed processing system, at least one processing device may transfer information on the communication medium to another processing device.
Client/server architecture
110
illustrated in
FIG. 1
a
is one type of distributed processing system. Client/server architecture
110
includes at least two processing devices, illustrated as client
105
and application server
103
. Additional clients may also be coupled to communication medium
104
, such as client
108
.
Typically, server
103
hosts business logic and/or coordinates transactions in providing a service to another processing device, such as client
103
and/or client
108
. Application server
103
is typically programmed with software for providing a service. The software may be programmed using a variety of programming models, such as Enterprise Java™ Bean (“EJB”)
100
b
as illustrated in
FIGS. 1
a-b.
The service may include, for example, retrieving and transferring data from a database, providing an image and/or calculating an equation. For example, server
103
may retrieve data from database
101
a
in persistent storage
101
over communication medium
102
in response to a request from client
105
. Application server
103
then may transfer the requested data over communication medium
104
to client
105
.
A client is a processing device which utilizes a service from a server and may request the service. Often a user
106
interacts with client
106
and may cause client
105
to request service over a communication medium
104
from application server
103
. A client often handles direct interactions with end users, such as accepting requests and displaying results.
A variety of different types of software may be used to program application server
103
and/or client
105
. One programming language is the Java™ programming language. Java™ application object code is loaded into a Java™ virtual machine (“JVM”). A JVM is a program loaded onto a processing device which emulates a particular machine or processing device. More information on the Java™ programming language may be obtained at http://www.javasoft.com, which is incorporated by reference herein.
FIG. 1
b
illustrates several Java™ Enterprise Application Programming Interfaces (“APIs”)
100
that allow Java™ application code to remain independent from underlying transaction systems, data-bases and network infrastructure. Java™ Enterprise APIs
100
include, for example, remote method invocation (“RMI”)
100
a,
EJBs
100
b,
and Java™ Naming and Directory Interface (JNDI)
100
c.
RMI
100
a
is a distributed programming model often used in peer-to-peer architecture described below. In particular, a set of classes and interfaces enables one Java™ object to call the public method of another Java™ object running on a different JVM.
An instance of EJB
100
b
is typically used in a client/server architecture described above. An instance of EJB
100
b
is a software component or a reusable pre-built piece of encapsulated application code that can be combined with other components. Typically, an instance of EJB
100
b
contains business logic. An EJB
100
b
instance stored on server
103
typically manages persistence, transactions, concurrency, threading, and security.
JNDI
100
c
provides directory and naming functions to Java™ software applications.
Client/server architecture
110
has many disadvantages. First, architecture
110
does not scale well because server
103
has to handle many connections. In other words, the number of clients which may be added to server
103
is limited. In addition, adding twice as many processing devices (clients) does not necessarily provide you with twice as much performance. Second, it is difficult to maintain application code on clients
105
and
108
. Third, architecture
110
is susceptible to system failures or a single point of failure. If server
101
fails and a backup is not available, client
105
will not be able to obtain the service.
FIG. 1
c
illustrates a multi-tier architecture
160
. Clients
151
,
152
manage direct interactions with end users, accepting requests and display results. Application server
153
hosts the application code, coordinates communications, synchronizations, and transactions. Database server
154
and portable storage device
155
provides durable transactional management of the data.
Multi-tier architecture
160
has similar client/server architecture
110
disadvantages described above.
FIG. 2
illustrates peer-to-peer architecture
214
. Processing devices
216
,
217
and
218
are coupled to communication medium
213
. Processing devices
216
,
217
, and
218
include network software
210
a,
210
b,
and
210
c
for communicating over medium
213
. Typically, each processing device in a peer-to-peer architecture has similar processing capabilities and applications. Examples of peer-to-peer program models include Common Object Request Broker Architecture (“CORBA”) and Distributed Object Component Model (“DCOM”) architecture.
In a platform specific distributed processing system, each processing device may run the same operating system. This allows the use of proprietary hardware, such as shared disks, multi-tailed disks, and high speed interconnects, for communicating between processing devices. Examples of platform-specific distributed processing systems include IBM® Corporation's S/390® Parallel Sysplex®, Compaq's Tandem Division Himalaya servers, Compaq's Digital Equipment Corporation™ (DEC™) Division OpenVMS™ Cluster software, and Microsoft® Corporation Windows NT® cluster services (Wolfpack).
FIG. 2
b
illustrates a transaction processing (TP) architecture
220
. In particular, TP architecture
220
illustrates a BEA® Systems, Inc. TUXEDO® architecture. TP monitor
224
is coupled to processing devices ATM
221
, PC
222
, and TP monitor
223
by communication medium
280
,
281
, and
282
, respectively. ATM
221
may be an automated teller machine, PC
222
may be a personal computer, and TP monitor
223
may be another transaction processor monitor. TP monitor
224
is coupled to back-end servers
225
,
226
, and
227
by communication mediums
283
,
284
, and
285
. Server
225
is coupled to persistent storage device
287
, storing database
289
, by communication medium
286
. TP monitor
224
includes a workflow controller
224
a
for routing service requests from processing devices, such as ATM
221
, PC
222
, or TP monitor
223
, to various servers such as server
225
,
226
and
227
. Work flow controller
224
a
enables (1) workload balancing between servers, (2) limited scalability or allowing for additional servers and/or clients, (3) fault tolerance of redundant backend servers (or a service request may be sent by a workflow controller to a server which has not failed), and (4) session concentration to limit the number of simultaneous connections to back-end servers. Examples of other transaction processing architectures include IBM® Corporation's CICS®, Compaq's Tandem Division Pathway/Ford/TS, Compaq's DEC™ ACMS, and Transarc Corporation's Encina.
TP architecture
220
also has many disadvantages. First, a failure of a single processing device or TP monitor
224
may render the network inoperable. Second, the scalability or number of processing devices (both servers and clients) coupled to TP monitor
224
may be limited by TP monitor
224
hardware and software. Third, flexibility in routing a client request to a server is limited. For example, if communication
Jacobs Dean B.
Langen Anno R.
BEA Systems Inc.
Fliesler Dubb Meyer & Lovejoy LLP
LandOfFree
Clustered enterprise Java™ having a message passing... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Clustered enterprise Java™ having a message passing..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Clustered enterprise Java™ having a message passing... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2914544