Teach yourself CORBA in 14 days

403 Pages·1998·1.519 MB·English

by  Jeremy Rosenberger

;-_=_Scrolldown to the Underground_=_-;
CORBA In 14 Days
http://kickme.to/tiger/
Teach Yourself CORBA In 14 Days
Table of Contents:
Sams' Teach Yourself CORBA
in 14 days
Introduction -
Week 1 at a Glance
Day 1 - Getting Familiar with CORBA
Day 2 - Understanding the CORBA Architecture
Day 3 - Mastering the Interface Definition Language (IDL)
Day 4 - Building a CORBA Application
Day 5 - Designing the System: A Crash Course in Object-Oriented Analysis and Design
Day 6 - Implementing Basic Application Capabilities
Day 7 - Using Exceptions to Perform Error Checking
Week 1 in Review
Week 2 at a Glance
Day 8 - Adding Automated Teller Machine (ATM) Capability
Day 9 - Using Callbacks to Add Push Capability
Day 10 - Learning About CORBA Design Issues
Day 11 - Using the Dynamic Invocation Interface (DII)
Day 12 - Exploring CORBAservices and CORBAfacilities
Day 13 - Developing for the Internet Using CORBA and Java
Day 14 - Web-Enabling the Bank Example with Java
Week 2 in Review
Appendixes
Appendix A - Answers to Quizzes and Exercises
Appendix B - CORBA Tools and Utilities
Appendix C - What Lies Ahead? The Future of CORBA
© Copyright, Macmillan Computer Publishing. All rights reserved.
Contents
Teach Yourself CORBA In 14 Days
Sams' Teach Yourself CORBA
in 14 days
Acknowledgments
First and foremost, the good people at Sams Publishing deserve many thanks for making this book
possible. In particular, acquisitions editor Steve Straiger is especially deserving of gratitude for his
generous flexibility with the development schedule.
I would also like to acknowledge my personal friend and colleague, Michael Jones, who encouraged me
to rise to the challenge of writing this book. Also worthy of recognition are my other colleagues at
Hughes Information Technology Systems, who were gracious enough to tolerate my highly
nontraditional work schedule (especially around deadline time).
Additionally, the folks at Visigenic Software deserve credit for making excellent software and for
making this software available for usable evaluation periods.
Finally, an honorable mention goes to Stonehenge Internet and to GTE Internet for their faithful, reliable
delivery of Internet service--which is indispensable for writing a book in this Information Age.
About the Author
Born and raised in Toledo, Ohio, Jeremy Rosenberger received his Bachelor's degree in computer
science and engineering from Cornell University in Ithaca, New York. Since then, Jeremy has lived in
Boston and St. Louis, and at present resides in Denver with his wife, Camilla.
Jeremy currently works as a software engineer for Hughes Information Systems in Aurora, Colorado,
where he develops applications by using a variety of tools such as C++, CORBA, Java, and software
agent technologies. He is a contributing author to Javology (http://www.javology.com/) and has
written two chapters of Special Edition Using JavaBeans (Que/Ziff-Davis Press, 1997), covering the use
of Java with CORBA, as well as a preview of the Java Platform for the Enterprise. He also aspires to
form a consulting firm catering to clients in the Denver area.
When he isn't working at developing software or writing his latest and greatest book, Jeremy can usually
be found spending time with his wife, building scale model cars, composing and playing music, or
playing volleyball. Occasionally, he can be found engaging in outdoor activities in the high altitudes of
the Rocky Mountains.
Although Jeremy is a man of many email addresses, he can always be reached at
[email protected].
Introduction
Welcome to Sams' Teach Yourself CORBA in 14 Days! This book explores the development of
distributed applications using the Common Object Request Broker Architecture (CORBA). In two
weeks, it introduces you to the fundamental concepts of CORBA, walks you through the development of
a simple CORBA application, and then starts you developing a more complex application. You'll learn
about CORBA's Interface Definition Language (IDL) and how to use it to describe interfaces between
application components. You'll also be introduced to the Object Management Group, the organization
responsible for developing the Object Management Architecture, a specification in which CORBA plays
one part. Additionally, you'll learn about the CORBA architecture and related components of the Object
Management Architecture--such as CORBAservices and CORBAfacilities--and see how these building
blocks are used to develop distributed enterprise applications. You'll gain familiarity with writing
CORBA applications in both C++ and Java, the two preeminent languages for CORBA development.
In addition to the 14 Lessons, two Appendixes introduce you to many of the CORBA development tools
available, and give you an overview of what the future holds for CORBA. Although CORBA can
sometimes move at the speed of a standard defined by a committee (not surprising, given the process
used by the OMG to adopt new standards), CORBA continues to make strides that ensure its place at the
forefront of distributed application development.
Assumptions
You'll get the most out of this book if you have the following:
l S ome knowledge of C++ or Java, although experience with any programming language will help
you to understand the concepts presented in this book.
l F amiliarity with the development tools, such as Visual C++, Java Development Kit (JDK), or other
development environments, on your platform(s) of choice.
l U nderstanding of object-oriented analysis and design concepts. Such knowledge isn't absolutely
necessary because this book introduces you to these concepts, but because CORBA is an
object-oriented architecture, you'll benefit most from reading this if you're already familiar with
object-oriented analysis and design.
The best way to learn any new subject is to practice and experiment. To follow the examples presented in
each chapter, as well as each quiz and exercise, you need access to the following:
l A computer of some kind. Because CORBA is cross-platform, almost any kind of computer will
do--from a Macintosh, to a PC running Windows, to a UNIX workstation. Any machine supported
by a CORBA development product (see the next bullet point) will do.
l A CORBA development product for your machine. Two of the more popular products include
IONA Technologies' Orbix and Visigenic Software's VisiBroker. Many vendors offer an
evaluation period for their products that provides more than enough time to complete this book.
The C++ examples were developed using VisiBroker for C++; the Java examples use Sun's Java
IDL package. However, the examples work with other products, with few or no changes.
l T he appropriate compiler and/or other software development tools necessary to support your
chosen CORBA development product. For instance, VisiBroker for C++ on Windows 95 or
Windows NT requires Visual C++ 4.2 or higher (although compilers from other vendors work as
well). For Java-based CORBA products, usually you only need a recent version of the Java
Development Kit (JDK).
Contents
© Copyright, Macmillan Computer Publishing. All rights reserved.
Teach Yourself CORBA In 14 Days
Previous chapter Contents
Day 1
Getting Familiar with CORBA
l T he Purpose of This Book
l B ackground: History of Distributed Systems
m T he Beginning: Monolithic Systems and Mainframes
m T he Revolution: Client/Server Architecture
m T he Evolution: Multitier Client/Server
m T he Next Generation: Distributed Systems
l W hy CORBA?
m E xploring CORBA Alternatives
l C ORBA History
m I ntroducing the Object Management Group (OMG)
m C ORBA 1.0
m C ORBA 2.0 and IIOP
l C ORBA Architecture Overview
m T he Object Request Broker (ORB)
m I nterface Definition Language (IDL)
m T he CORBA Communications Model
m T he CORBA Object Model
m C ORBA Clients and Servers
m S tubs and Skeletons
m B eyond the Basics: CORBAservices and CORBAfacilities
l S ummary
l Q &A
l W orkshop
m Q uiz
The Purpose of This Book
Certainly, this isn't the first book to be written on the subject of the Common Object Request Broker
Architecture (CORBA)--not by a long shot. However, among CORBA books currently on shelves, it
might be unique in its approach. At the time this book was written, few, if any, texts were available that
covered CORBA at an introductory level. This book attempts to fill that gap.
CORBA is not a subject for the fainthearted, to be sure. Although development tools that hide some of
the complexity of CORBA exist, if you embark on a project to develop a reasonably sophisticated
CORBA application, chances are that you will experience some of CORBA's complexities firsthand.
However, though there might be a steep learning curve associated with CORBA, a working knowledge
of CORBA fundamentals is well within the grasp of any competent programmer.
For the purposes of this book, it is assumed that you already have a good deal of programming
experience. CORBA is a language-independent architecture, but because C++ and Java are the principal
languages used to develop CORBA applications, it would be preferable if you had experience with one
of these languages. (Most of the examples are written in C++, with a healthy dose of Java thrown in for
good measure.) It wouldn't hurt if you were familiar with object-oriented analysis and design concepts
either, but just in case you need a refresher, this book will help you review these concepts.
Operating under the assumption that learning CORBA is a surmountable (if daunting) goal for most
programmers, this book begins teaching the fundamentals of CORBA, starting with an overview of the
architecture. You'll then move on to a primer on the Interface Definition Language (IDL), a cornerstone
on which most CORBA applications are based. After that, you'll start building CORBA applications, and
before you know it, you'll be exposed to advanced concepts and design issues, along with other useful
things such as CORBAservices, CORBAfacilities, and the Dynamic Invocation Interface, or DII (don't
worry--you'll learn what all this means, in due time). All this--and more--in a mere 14 days.
What this book does not do--indeed, cannot do--is make you a CORBA expert overnight (or even in 14
days, for that matter). It does put you well on your way to mastering CORBA. Keep in mind that
CORBA is a complex architecture, full of design issues and tradeoffs as well as implementation nuances.
As such, it can only be mastered through experience--something you will gain only by designing and
developing CORBA applications. Perhaps this book does not make you an expert in all things CORBA,
but it does put you on the right track toward achieving that goal.
Background: History of Distributed Systems
If you're interested enough in CORBA to be reading this book, you probably know a thing or two already
about distributed systems. Distributed systems have been around, in one form or another, for some time,
although they haven't always been called that and they certainly haven't always had the flexibility that
they do now. To discover where CORBA fits in, let's briefly review the history of distributed systems,
starting with the venerable mainframe.
The Beginning: Monolithic Systems and Mainframes
In the beginning (or close to it), there was the mainframe. Along with it came hierarchical database
systems and dumb terminals, also known as green screens. Mainframes usually cost a great deal to
maintain but were capable of serving large numbers of users and had the advantage (or disadvantage,
depending on one's point of view) of being centrally managed.
Software systems written for mainframes were often monolithic--that is, the user interface, business
logic, and data access functionality were all contained in one large application. Because the dumb
terminals used to access mainframes didn't do any of their own processing, the entire application ran in
the mainframe itself, thus making the monolithic architecture reasonable. A typical monolithic
application architecture is illustrated in Figure 1.1.
Figure 1.1. Typical monolithic application architecture.
The Revolution: Client/Server Architecture
The advent of the PC made possible a dramatic paradigm shift from the monolithic architecture of
mainframe-based applications. Whereas these applications required the mainframe itself to perform all
the processing, applications based on the client/server architecture allowed some of that processing to be
offloaded to PCs on the users' desktops.
Along with the client/server revolution came the proliferation of UNIX-based servers. Many applications
simply did not require the massive power of mainframes, and because the client/server architecture was
capable of moving much of the processing load to the desktop PC, these smaller UNIX-based server
machines were often more cost-effective than mainframes. Also, these machines were much more
affordable to small businesses than mainframes, which were often simply out of reach for companies
with relatively small bank account balances. Still another benefit was the empowerment of individual
departments within an organization to deploy and manage their own servers. The result was that these
departments could be more responsive to their specific needs when developing their own applications,
rather than having to jump through proverbial hoops to get the department controlling the mainframes to
develop applications, as was often the case. Finally, whereas terminals were typically restricted to
running only applications on the mainframe, a PC was capable of performing many other tasks
independently of the mainframe, further enhancing its usefulness as a desktop machine.
Client/server applications typically distributed the components of the application so that the database
would reside on the server (whether a UNIX box or mainframe), the user interface would reside on the
client, and the business logic would reside in either, or both, components. When changes were made to
parts of the client component, new copies of the client component (usually executables or a set of
executables) had to be distributed to each user.
With the advent of multitier client/server architecture (discussed in the next section), the "original"
client/server architecture is now referred to as "two-tier" client/server. The two-tier client/server
architecture is illustrated in Figure 1.2.
Figure 1.2. Two-tier client/server architecture.
The Evolution: Multitier Client/Server
The client/server architecture was in many ways a revolution from the old way of doing things. Despite
solving the problems with mainframe-based applications, however, client/server was not without faults of
its own. For example, because database access functionality (such as embedded database queries) and
business logic were often contained in the client component, any changes to the business logic, database
access, or even the database itself, often required the deployment of a new client component to all the
users of the application. Usually, such changes would break earlier versions of the client component,
resulting in a fragile application.
The problems with the traditional client/server (now often called "two-tier" client/server) were addressed
by the multitier client/server architecture. Conceptually, an application can have any number of tiers, but
the most popular multitier architecture is three-tier, which partitions the system into three logical tiers:
the user interface layer, the business rules layer, and the database access layer. A three-tier client/server
architecture is illustrated in Figure 1.3.
Figure 1.3. Three-tier client/server architecture.
Multitier client/server architecture enhances the two-tier client/server architecture 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.
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).
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.
Note: 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