ch01.htm

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

<P>The Object Management Group (OMG), established in 1989 with eight original members,
is a 760-plus-member organization whose charter is to &quot;provide a common architectural
framework for object-oriented applications based on widely available interface specifications.&quot;
That's a rather tall order, but the OMG achieves its goals with the establishment
of the Object Management Architecture (OMA), of which CORBA is a part. This set of
standards delivers the common architectural framework on which applications are built.
Very briefly, the OMA consists of the Object Request Broker (ORB) function, object
services (known as CORBAservices), common facilities (known as CORBAfacilities),
domain interfaces, and application objects. CORBA's role in the OMA is to implement
the Object Request Broker function. For the majority of this book, you will be concentrating
on CORBA itself, occasionally dabbling into CORBAservices and CORBAfacilities.
<H3><A NAME="Heading11"></A><FONT COLOR="#000077">CORBA 1.0</FONT></H3>
<P>Following the OMG's formation in 1989, CORBA 1.0 was introduced and adopted in
December 1990. It was followed in early 1991 by CORBA 1.1, which defined the Interface
Definition Language (IDL) as well as the API for applications to communicate with
an Object Request Broker (ORB). (These are concepts that you'll explore in much greater
detail on Day 2.) A 1.2 revision appeared shortly before CORBA 2.0, which with its
added features quickly eclipsed the 1.x revisions. The CORBA 1.x versions made an
important first step toward object interoperability, allowing objects on different
machines, on different architectures, and written in different languages to communicate
with each other.
<H3><A NAME="Heading12"></A><FONT COLOR="#000077">CORBA 2.0 and IIOP</FONT></H3>
<P>CORBA 1.x was an important first step in providing distributed object interoperability,
but it wasn't a complete specification. Although it provided standards for IDL and
for accessing an ORB through an application, its chief limitation was that it did
not specify a standard protocol through which ORBs could communicate with each other.
As a result, a CORBA ORB from one vendor could not communicate with an ORB from another
vendor, a restriction that severely limited interoperability among distributed objects.</P>
<P>Enter CORBA 2.0. Adopted in December 1994, CORBA 2.0's primary accomplishment
was to define a standard protocol by which ORBs from various CORBA vendors could
communicate. This protocol, known as the Internet Inter-ORB Protocol (IIOP, pronounced
&quot;eye-op&quot;), is required to be implemented by all vendors who want to call
their products CORBA 2.0 compliant. Essentially, IIOP ensures true interoperability
among products from numerous vendors, thus enabling CORBA applications to be more
vendor-independent. IIOP, being the <I>Internet</I> Inter-ORB Protocol, applies only
to networks based on TCP/IP, which includes the Internet and most intranets.</P>
<P>The CORBA standard continues to evolve beyond 2.0; in September 1997, the 2.1
version became available, followed shortly by 2.2; 2.3 is expected in early 1998.
(The OMG certainly is keeping itself busy!) These revisions introduce evolutionary
(not revolutionary) advancements in the CORBA architecture.
<H2><A NAME="Heading13"></A><FONT COLOR="#000077">CORBA Architecture Overview</FONT></H2>
<P>Finally, having learned the history and reasons for the existence of CORBA, you're
ready to examine the CORBA architecture. You'll cover the architecture in greater
detail on Day 2, but Day 1 provides you with a very general overview--an executive
summary, if you will--of what composes the CORBA architecture.</P>
<P>First of all, CORBA is an object-oriented architecture. CORBA objects exhibit
many features and traits of other object-oriented systems, including interface inheritance
and polymorphism. What makes CORBA even more interesting is that it provides this
capability even when used with nonobject-oriented languages such as C and COBOL,
although CORBA maps particularly well to object-oriented languages like C++ and Java.</P>
<P><B>New Term: </B>I<I>nterface inheritance </I>is a concept that should be familiar
to Objective C and Java developers. In the contrasting <I>implementation inheritance,</I>
an implementation unit (usually a class) can be derived from another. By comparison,
interface inheritance allows an interface to be derived from another. Even though
interfaces can be related through inheritance, the implementations for those interfaces
need not be.
<H3><A NAME="Heading14"></A><FONT COLOR="#000077">The Object Request Broker (ORB)</FONT></H3>
<P>Fundamental to the Common Object Request Broker Architecture is the Object Request
Broker, or ORB. (That the ORB acronym appears within the CORBA acronym was just too
much to be coincidental.) An ORB is a software component whose purpose is to facilitate
communication between objects. It does so by providing a number of capabilities,
one of which is to locate a remote object, given an object reference. Another service
provided by the ORB is the marshaling of parameters and return values to and from
remote method invocations. (Don't worry if this explanation doesn't make sense; the
ORB is explained in much greater detail on Day 2.) Recall that the Object Management
Architecture (OMA) includes a provision for ORB functionality; CORBA is the standard
that implements this ORB capability. You will soon see that the use of ORBs provides
platform independence to distributed CORBA objects.
<H3><A NAME="Heading15"></A><FONT COLOR="#000077">Interface Definition Language (IDL)</FONT></H3>
<P>Another fundamental piece of the CORBA architecture is the use of the Interface
Definition Language (IDL). IDL, which specifies interfaces between CORBA objects,
is instrumental in ensuring CORBA's language independence. Because interfaces described
in IDL can be mapped to any programming language, CORBA applications and components
are thus independent of the language(s) used to implement them. In other words, a
client written in C++ can communicate with a server written in Java, which in turn
can communicate with another server written in COBOL, and so forth.</P>
<P>One important thing to remember about IDL is that it is not an implementation
language. That is, you can't write applications in IDL. The sole purpose of IDL is
to define interfaces; providing implementations for these interfaces is performed
using some other language. When you study IDL more closely on Day 3, you'll learn
more about this and other assorted facts about IDL.
<H3><A NAME="Heading16"></A><FONT COLOR="#000077">The CORBA Communications Model</FONT></H3>
<P><B>New Term: </B>CORBA uses the notion of <I>object references</I> (which in CORBA/IIOP
lingo are referred to as Interoperable Object References, or IORs) to facilitate
the communication between objects. When a component of an application wants to access
a CORBA object, it first obtains an IOR for that object. Using the IOR, the component
(called a <I>client</I> of that object) can then invoke methods on the object (called
the <I>server</I> in this instance).</P>
<P>In CORBA, a <I>client</I> is simply any application that uses the services of
a CORBA object; that is, an application that invokes a method or methods on other
objects. Likewise, a <I>server</I> is an application that creates CORBA objects and
makes the services provided by those objects available to other applications. A much
more detailed discussion of CORBA clients and servers is presented on Day 2.</P>
<P>As mentioned previously, CORBA ORBs usually communicate using the Internet Inter-ORB
Protocol (IIOP). Other protocols for inter-ORB communication exist, but IIOP is fast
becoming the most popular, first of all because it is the standard, and second because
of the popularity of TCP/IP (the networking protocols used by the Internet), a layer
that IIOP sits on top of. CORBA is independent of networking protocols, however,
and could (at least theoretically) run over any type of network protocols. For example,
there are also implementations of CORBA that run over DCE rather than over TCP/IP,
and there is also interest in running CORBA over ATM and SS7.
<H3><A NAME="Heading17"></A><FONT COLOR="#000077">The CORBA Object Model</FONT></H3>
<P>In CORBA, all communication between objects is done through object references
(again, these are known as Interoperable Object References, or IORs, if you're using
IIOP). Furthermore, visibility to objects is provided <I>only</I> through passing
references to those objects; objects cannot be passed by value (at least in the current
specification of CORBA). In other words, remote objects in CORBA <I>remain</I> remote;
there is currently no way for an object to move or copy itself to another location.
(You'll explore this and other CORBA limitations and design issues on Day 10.)</P>
<P>Another aspect of the CORBA object model is the Basic Object Adapter (BOA), a
concept that you'll also explore on Day 2. A BOA basically provides the common services
available to all CORBA objects.
<H3><A NAME="Heading18"></A><FONT COLOR="#000077">CORBA Clients and Servers</FONT></H3>
<P>Like the client/server architectures, CORBA maintains the notions of <I>clients</I>
and <I>servers</I>. In CORBA, a component can act as both a client and as a server.
Essentially, a component is considered a server if it contains CORBA objects whose
services are accessible to other objects. Likewise, a component is considered a client
if it accesses services from some other CORBA object. Of course, a component can
simultaneously provide and use various services, and so a component can be considered
a client or a server, depending on the scenario in question.
<H3><A NAME="Heading19"></A><FONT COLOR="#000077">Stubs and Skeletons</FONT></H3>
<P>When implementing CORBA application components, you will encounter what are known
as <I>client</I> <I>stubs</I> and <I>server</I> <I>skeletons</I>. A client stub is
a small piece of code that allows a client component to access a server component.
This piece of code is compiled along with the client portion of the application.
Similarly, server skeletons are pieces of code that you &quot;fill in&quot; when
you implement a server. You don't need to write the client stubs and server skeletons
themselves; these pieces of code are generated when you compile IDL interface definitions.
Again, you'll soon see all this firsthand.
<H3><A NAME="Heading20"></A><FONT COLOR="#000077">Beyond the Basics: CORBAservices
and CORBAfacilities</FONT></H3>
<P>In addition to the CORBA basics of allowing objects to communicate with each other,
recall that the OMA--of which CORBA is a part--also provides additional capabilities
in the form of CORBAservices and CORBAfacilities. As you'll find out, CORBAservices
and CORBAfacilities provide both horizontal (generally useful to all industries)
and vertical (designed for specific industries) services and facilities. You'll look
at the capabilities provided in greater detail on Day 12, after which you'll get
the opportunity to use some of this functionality in a CORBA application.
<H2><A NAME="Heading21"></A><FONT COLOR="#000077">Summary</FONT></H2>
<P>Today you had a very brief overview of the CORBA architecture, along with a history
of business application development and where CORBA fits in. You now know what you
can expect to get out of this book--you won't become a CORBA expert overnight, but
you will gain valuable exposure to the process of designing and developing CORBA-based
applications.</P>
<P>In the next few days, you'll explore the CORBA architecture in much greater detail,
learn more than you ever wanted to know about IDL, and you'll be well on your way
to developing CORBA applications.
<H2><A NAME="Heading22"></A><FONT COLOR="#000077">Q&amp;A</FONT></H2>

<DL>
	<DD><B>Q I'm still not very clear on why I would want to use CORBA as opposed to
	some other method of interprocess communication.</B><BR>
	<B><BR>
	A </B>There are a few areas where CORBA really shines. For applications that have
	various components written in different languages and/or need to run on different
	platforms, CORBA can make a lot of sense. CORBA takes care of some potentially messy
	details for you, such as automatically converting (through the marshaling process)
	number formats between different machines. In addition, CORBA provides an easily
	understood abstraction of distributed applications, consisting of object-oriented
	design, an exception model, and other useful concepts. But where CORBA is truly valuable
	is in applications used throughout an enterprise. CORBA's many robust features--as
	well as those provided by the OMA CORBAservices and CORBAfacilities--and especially
	CORBA's scalability, make it well suited for enterprise applications.<BR>
	<B><BR>
	Q What is IDL and why is it useful?<BR>
	<BR>
	A </B>IDL, or Interface Definition Language, will be covered in greater detail over
	the next two Days. For now, it is useful to understand that the value in IDL comes
	from its abstraction of various language, hardware, and operating system architectures.
	For example, the IDL <TT>long</TT> type will automatically be translated to the numeric
	type appropriate for whatever architecture the application is run on. In addition,
	because IDL is language-independent, it can be used to define interfaces for objects
	that are implemented in any language.
</DL>

<H2><A NAME="Heading23"></A><FONT COLOR="#000077">Workshop</FONT></H2>
<P>The following section will help you test your comprehension of the material presented
today and put what you've learned into practice. You'll find the answers to the quiz
in Appendix A. On most days, a few exercises will accompany the quiz; today, because
no real &quot;working knowledge&quot; material was presented, there are no exercises.
<H3><A NAME="Heading24"></A><FONT COLOR="#000077">Quiz</FONT></H3>

<DL>
	<DD><B>1</B>. What does IIOP stand for and what is its significance?<BR>
	<B>2</B>. What is the relationship between CORBA, OMA, and OMG?<BR>
	<B>3</B>. What is a client stub?<BR>
	<B>4</B>. What is an object reference? An IOR?<FONT COLOR="#000077"></FONT>
</DL>

<CENTER>
<P>
<HR>
<A HREF="../fm/fm.htm"><IMG SRC="../button/previous.gif" WIDTH="128" HEIGHT="28"
ALIGN="BOTTOM" ALT="Previous chapter" BORDER="0"></A><A HREF="../ch02/ch02.htm"><IMG
SRC="../button/next.gif" WIDTH="128" HEIGHT="28" ALIGN="BOTTOM" ALT="Next chapter"
BORDER="0"></A><A HREF="../index.htm"><IMG SRC="../button/contents.gif" WIDTH="128"
HEIGHT="28" ALIGN="BOTTOM" ALT="Contents" BORDER="0"></A><BR>
<BR>
<BR>
<IMG SRC="../button/corp.gif" WIDTH="284" HEIGHT="45" ALIGN="BOTTOM" ALT="Macmillan Computer Publishing USA"
BORDER="0"></P>

<P>&#169; <A HREF="../copy.htm">Copyright</A>, Macmillan Computer Publishing. All
rights reserved.
</CENTER>


</BODY>

</HTML>