ch01.htm

corba比较入门级的介绍详细间接了corba访问发布各种细节。

in two ways: First, and perhaps most importantly, it makes the application less fragile
by further insulating the client from changes in the rest of the application. Also,
because the executable components are more fine-grained, it allows more flexibility
in the deployment of an application.</P>
<P>Multitier client/server reduces application fragility by providing more insulation
and separation between layers. The user interface layer communicates only with the
business rules layer, never directly with the database access layer. The business
rules layer, in turn, communicates with the user interface layer on one side and
the database access layer on the other. Thus, changes in the database access layer
will not affect the user interface layer because they are insulated from each other.
This architecture enables changes to be made in the application with less likelihood
of affecting the client component (which, remember, has to be redistributed when
there are any changes to it).</P>
<P>Because the multitier client/server architecture partitions the application into
more components than traditional two-tier client/server, it also allows more flexibility
in deployment of the application. For example, Figure 1.3 depicts a system in which
the business rules layer and database access layer, although they are separate logical
entities, are on the same server machine. It is also possible to put each server
component on a separate machine. Indeed, multiple business logic components (and
multiple database access components, if multiple databases are being used) can be
created for a single application, distributing the processing load and thus resulting
in a more robust, scalable application.


<BLOCKQUOTE>
	<P>
<HR>
<B>Note: </B>It is interesting to note that the multitier client/server architecture
	might actually have had its roots in mainframe applications. COBOL applications on
	IBM mainframes could define the user interface by using a tool called Message Format
	Service (MFS). MFS abstracted the terminal type (terminals could, for instance, have
	varying numbers of rows and columns) from the rest of the application. Similarly,
	applications could specify the database interfaces as well. Although the application
	would still run in one monolithic chunk, the available tools enabled the design of
	applications using a logical three-tier architecture. 
<HR>


</BLOCKQUOTE>

<H3><A NAME="Heading6"></A><FONT COLOR="#000077">The Next Generation: Distributed
Systems</FONT></H3>
<P>The next logical step in the evolution of application architectures is the distributed
system model. This architecture takes the concept of multitier client/server to its
natural conclusion. Rather than differentiate between business logic and data access,
the distributed system model simply exposes all functionality of the application
as objects, each of which can use any of the services provided by other objects in
the system, or even objects in other systems. The architecture can also blur the
distinction between &quot;client&quot; and &quot;server&quot; because the client
components can also create objects that behave in server-like roles. The distributed
system architecture provides the ultimate in flexibility.</P>
<P>The distributed system architecture achieves its flexibility by encouraging (or
enforcing) the definition of specific component interfaces. The interface of a component
specifies to other components what services are offered by that component and how
they are used. As long as the interface of a component remains constant, that component's
implementation can change dramatically without affecting other components. For example,
a component that provides customer information for a company can store that information
in a relational database. Later, the application designers might decide that an object-oriented
database would be more appropriate. The designers can make any number of changes
to the component's implementation--even sweeping changes such as using a different
type of database--provided that they leave the component's interface intact. Again,
as long as the interface of that component remains the same, the underlying implementation
is free to change.</P>
<P><B>New Term: </B>An <I>interface</I> defines the protocol of communication between
two separate components of a system. (These components can be separate processes,
separate objects, a user and an application--any separate entities that need to communicate
with each other.) The interface describes what services are provided by a component
and the protocol for using those services. In the case of an object, the interface
can be thought of as the set of methods defined by that object, including the input
and output parameters. An interface can be thought of as a contract; in a sense,
the component providing an interface promises to honor requests for services as outlined
in the interface.</P>
<P>Distributed systems are really multitier client/server systems in which the number
of distinct clients and servers is potentially large. One important difference is
that distributed systems generally provide additional services, such as directory
services, which allow various components of the application to be located by others.
Other services might include a transaction monitor service, which allows components
to engage in transactions with each other.</P>
<P><B>New Term: </B><I>Directory services</I> refers to a set of services that enable
objects--which can be servers, businesses, or even people--to be located by other
objects. Not only can the objects being looked up differ in type, but the directory
information itself can vary as well. For example, a telephone book would be used
to locate telephone numbers and postal addresses; an email directory would be used
to locate email addresses. Directory services encompass all such information, usually
grouping together related information (for example, there are separate volumes of
the yellow pages for different cities; contents of each volume are further divided
into types of businesses).</P>
<P><B>New Term: </B>A <I>transaction monitor</I> service oversees transactions on
behalf of other objects. A transaction, in turn, is an operation or set of operations
that must be performed <I>atomically</I>; that is, either all objects involved in
the transaction must <I>commit</I> the transaction (update their own records) or
all objects involved must <I>abort</I> the transaction (return to their original
state before the transaction was initiated). The result is that whether a transaction
commits or aborts, all involved objects will be in a consistent state. It is the
job of a transaction monitor to provide transaction-related services to other objects.</P>
<P>To sum up, business applications have evolved over a period of time from a relatively
rigid monolithic architecture to an extremely flexible, distributed one. Along the
way, application architectures have offered increasing robustness because of the
definitions of interfaces between components and the scalability of applications
(furnished in part by the capability to replicate server components on different
machines). Additionally, services have been introduced that enable the end user of
an application to wade through the myriad of available services. Those who have been
designing and developing business applications since the days of mainframes have
certainly had an interesting ride.
<H2><A NAME="Heading7"></A><FONT COLOR="#000077">Why CORBA?</FONT></H2>
<P>So far, in this evolution of business applications from the monolithic mainframe
architecture to the highly decentralized distributed architecture, no mention has
been made of CORBA. Therefore, you might be asking yourself at this point where CORBA
fits in to all this. The answer, as you will see, is emphasized throughout the rest
of this book. Recall that distributed systems rely on the definition of interfaces
between components and on the existence of various services (such as directory registration
and lookup) available to an application. CORBA provides a standard mechanism for
defining the interfaces between components as well as some tools to facilitate the
implementation of those interfaces using the developer's choice of languages. In
addition, the Object Management Group (the organization responsible for standardizing
and promoting CORBA) specifies a wealth of standard services, such as directory and
naming services, persistent object services, and transaction services. Each of these
services is defined in a CORBA-compliant manner, so they are available to all CORBA
applications. Finally, CORBA provides all the &quot;plumbing&quot; that allows various
components of an application--or of separate applications--to communicate with each
other.</P>
<P><B>New Term: </B>The capabilities of CORBA don't stop there. Two features that
CORBA provides--features that are a rarity in the computer software realm--are <I>platform
independence</I> and <I>language independence.</I> Platform independence means that
CORBA objects can be used on any platform for which there is a CORBA ORB implementation
(this includes virtually all modern operating systems as well as some not-so-modern
ones). Language independence means that CORBA objects and clients can be implemented
in just about any programming language. Furthermore, CORBA objects need not know
which language was used to implement other CORBA objects that they talk to. Soon
you will see the components of the CORBA architecture that make platform independence
and language independence possible.
<H3><A NAME="Heading8"></A><FONT COLOR="#000077">Exploring CORBA Alternatives</FONT></H3>
<P>When designing and implementing distributed applications, CORBA certainly isn't
a developer's only choice. Other mechanisms exist by which such applications can
be built. Depending on the nature of the application--ranging from its complexity
to the platform(s) it runs on to the language(s) used to implement it--there are
a number of alternatives for a developer to consider. In this section you'll briefly
explore some of the alternatives and see how they compare to CORBA.
<H4><FONT COLOR="#000077">Socket Programming</FONT></H4>
<P><B>New Term: </B>In most modern systems, communication between machines, and sometimes
between processes in the same machine, is done through the use of <I>sockets.</I>
Simply put, a socket is a channel through which applications can connect with each
other and communicate. The most straightforward way to communicate between application
components, then, is to use sockets directly (this is known as <I>socket programming</I>),
meaning that the developer writes data to and/or reads data from a socket.</P>
<P>The Application Programming Interface (API) for socket programming is rather low-level.
As a result, the overhead associated with an application that communicates in this
fashion is very low. However, because the API is low-level, socket programming is
not well-suited to handling complex data types, especially when application components
reside on different types of machines or are implemented in different programming
languages. Whereas direct socket programming can result in very efficient applications,
the approach is usually unsuitable for developing complex applications.
<H4><FONT COLOR="#000077">Remote Procedure Call (RPC)</FONT></H4>
<P><B>New Term: </B>One rung on the ladder above socket programming is <I>Remote
Procedure Call (RPC).</I> RPC provides a function-oriented interface to socket-level
communications. Using RPC, rather than directly manipulating the data that flows
to and from a socket, the developer defines a function--much like those in a functional
language such as C--and generates code that makes that function look like a normal
function to the caller. Under the hood, the function actually uses sockets to communicate
with a remote server, which executes the function and returns the result, again using
sockets.</P>
<P>Because RPC provides a function-oriented interface, it is often much easier to
use than raw socket programming. RPC is also powerful enough to be the basis for
many client/server applications. Although there are varying incompatible implementations
of RPC protocol, a standard RPC protocol exists that is readily available for most
platforms.
<H4><FONT COLOR="#000077">OSF Distributed Computing Environment (DCE)</FONT></H4>
<P>The Distributed Computing Environment (DCE), a set of standards pioneered by the
Open Software Foundation (OSF), includes a standard for RPC. Although the DCE standard
has been around for some time, and was probably a good idea, it has never gained
wide acceptance and exists today as little more than an historical curiosity.
<H4><FONT COLOR="#000077">Microsoft Distributed Component Object Model (DCOM)</FONT></H4>
<P>The Distributed Component Object Model (DCOM), Microsoft's entry into the distributed
computing foray, offers capabilities similar to CORBA. DCOM is a relatively robust
object model that enjoys particularly good support on Microsoft operating systems
because it is integrated with Windows 95 and Windows NT. However, being a Microsoft
technology, the availability of DCOM is sparse outside the realm of Windows operating
systems. Microsoft is working to correct this disparity, however, in partnering with
Software AG to provide DCOM on platforms other than Windows. At the time this was
written, DCOM was available for the Sun Solaris operating system, with support promised
for Digital UNIX, IBM MVS, and other operating systems by the end of the year. By
the time you read this, some or all of these ports will be available. (More information
on the ports of DCOM to other platforms is available at <TT>http://www.softwareag.com/corporat/dcom/default.htm</TT>.)</P>
<P>Microsoft has, on numerous occasions, made it clear that DCOM is best supported
on Windows operating systems, so developers with cross-platform interests in mind
would be well-advised to evaluate the capabilities of DCOM on their platform(s) of
interest before committing to the use of this technology. However, for the development
of Windows-only applications, it is difficult to imagine a distributed computing
framework that better integrates with the Windows operating systems.</P>
<P>One interesting development concerning CORBA and DCOM is the availability of CORBA-DCOM
bridges, which enable CORBA objects to communicate with DCOM objects and vice versa.
Because of the &quot;impedance mismatch&quot; between CORBA and DCOM objects (meaning
that there are inherent incompatibilities between the two that are difficult to reconcile),
the CORBA-DCOM bridge is not a perfect solution, but it can prove useful in situations
where both DCOM and CORBA objects might be used.
<H4><FONT COLOR="#000077">Java Remote Method Invocation (RMI)</FONT></H4>
<P>The tour of exploring CORBA alternatives stops with Java Remote Method Invocation
(RMI), a very CORBA-like architecture with a few twists. One advantage of RMI is
that it supports the passing of objects by value, a feature not (currently) supported
by CORBA. A disadvantage, however, is that RMI is a Java-only solution; that is,
RMI clients and servers must be written in Java. For all-Java applications--particularly
those that benefit from the capability to pass objects by value--RMI might be a good
choice, but if there is a chance that the application will later need to interoperate
with applications written in other languages, CORBA is a better choice. Fortunately,
full CORBA implementations already exist for Java, ensuring that Java applications
interoperate with the rest of the CORBA world.
<H2><A NAME="Heading9"></A><FONT COLOR="#000077">CORBA History</FONT></H2>
<P>Now that you know a little bit of CORBA's background and its reason for existence,
it seems appropriate to briefly explore some of the history of CORBA to understand
how it came into being.
<H3><A NAME="Heading10"></A><FONT COLOR="#000077">Introducing the Object Management
Group (OMG)</FONT></H3>