[ruby-talk:03658] Components and Objects and Ruby (long post, partly OT)

Hi,

I wanted to draw your attention to an article that I have included below,
titled "MAIN ARTICLE: OBJECTS AND COMPONENTS".

Apart from being an interesting topic of discussion in its own right, I am
interested in what others think are Ruby's advantages in this regard, and
how others might approach the development of component systems from a Ruby
perspective.

Conrad

((The following is posted with the permission of the owner, subject to the
condition of including everything below; but please feel free to severely
trim replies in the usual manner.))

***************************************************
ObjectWatch Newsletter Number 28 (June 20, 2000)
Focus on Middle Tier Components and Web-Commerce
For printing, we suggest the HTML version of this newsletter at
http://www.objectwatch.com/issue_28.htm, which is usually available a
few days after the emailed version.
***************************************************
Feel free to forward this newsletter, but don't make any changes. Thanks.
There are now over 13,000 direct subscribers to this newsletter and well
over 52,000 readers!

For your own free email subscription, send mail to
[e-mail] saying:

subscribe your-name,your-email
For example,
subscribe Roger Sessions,[e-mail]

To unsubscribe, send mail to [e-mail] saying
unsubscribe your-name,your e-mail
***************************************************
CONTENTS
- Quotation of the Month: The CORBA Middle Tier
- Main Article: Objects and Components
- Upcoming Public Seminars with Roger Sessions: Vancouver BC, Seattle,
Burbank, Boston, Washington DC, New York City, Toronto, Dallas,
Denver, Philadelphia, Hartford, Rochester, Sydney, Melbourne
- New and Noteworthy Web Sites: The ServerSide.com
- Letters from Very Important People: Paul Harmon
- Great Job Opportunity for Instructors at ObjectWatch
- About ObjectWatch
***************************************************
QUOTATION OF THE MONTH: THE CORBA MIDDLE TIER

Obviously, because the CCM specification [the OMG specification for the
CORBA Component Model, the middle tier infrastructure that competes
with both EJB and COM+] was only approved in late 1999, it will be a
while before any vendor offers an implementation of the new model. And,
even then, as I suggested, it will probably only be an implementation of the
core CCM model, not an implementation of the entire specification. Under
the circumstances, I wouldn't expect the CCM standard to exert any
significant influence on the component market before 2001, at the earliest.
Moreover, given how well-established MTS/COM+ and EJB components
are, it's hard to imagine CCM will ever capture a large segment of the
server-side component market.

- Paul Harmon
Editor, Component Development Strategies Newsletter
http://www-4.ibm.com/software/developer/library/corba-comp-
model/index.html
(Paul Harmon is a prominent CORBA spokesperson)

This month's winner of the Quotation of the Month Contest is Roger
Sessions.  He gets a personally autographed copy of Roger Sessions's new
book, "COM+ and the Battle for the Middle Tier".  Because Roger already
has a copy of this incredible book, he is donating this copy to Paul
Harmon. Send in your nominations for Quotation of the Month to
[e-mail].
***************************************************
MAIN ARTICLE: OBJECTS AND COMPONENTS
At seven o'clock in the morning, there are some things I just don't want to
know about. Larry's lymphatic system, for example. Don't get me wrong.
I'm glad he has one. I just don't want to know the details. Especially
before
I have had my first Doppio Macchiato of the morning.

I feel the same about Larry's cortex, cerebellum, medulla, liver, ligaments,
olfactory lobes, and duodenum. Especially his duodenum.  As long as
Larry can get all these pieces coordinated in such a way that when I ask for
my Doppio, I get my Doppio, and that I get it with exactly one sugar, extra
foam, and in a preheated small porcelain cup, I am happy. It takes so
little,
after all, to please me. Starbucks should pay me to come in.

Not everybody shares my ambivalence about the Larry's bits and pieces.
Take Larry's doctor, for example. From Larry's doctor's perspective,
whether or not Larry can pour a proper 18 second Doppio Macchiato is
irrelevant. Larry's doctor only cares that Larry's hip bone is connected to
his thigh bone.

There is a good reason that Larry's doctor cares about all the Larry details
while I don't. Larry's doctor's focus is on how Larry works. My focus is on
what Larry can do. And a subset of what he can do at that, namely, make
Doppio Macchiatos.

It's not that I am right and Larry's doctor is wrong. It's just that we have
different interests in Larry, and therefore we each deal with Larry at a
different level of abstraction. Larry would get worried if his doctor asked
him a lot of questions about his Doppio skills. And he would get even
more worried if I started directing my morning Doppio requests to his
duodenum.

If Larry was a piece of software, he would be a component instance. The
software equivalent of Larry's innards (his ligaments, duodenum, etc.)
would be objects. Larry is packaged as a component, but he is made up of
object innards. The difference between these two levels of abstraction may
seem obvious, but it is amazing how many people confuse them. So let's
make sure we understand the difference between component packages and
object innards.

A component is a blob of software that encapsulates the implementation of
some serious business process logic (like making a Doppio, or processing a
credit card). What, exactly, the component can do depends on the type of
component it is. The type of component I care about at 7:00 in the morning
is the StarBucksEmployee component. I am happy to work with Sarah,
Larry, or Samantha, all instances of a StarBucksEmployee and therefore
any of which are capable of jumpstarting my morning routine.

You communicate with a component instance through a well defined
interface. The interface defines the operations that the component instance
can do for you. The definition of one of these operations we call a method.
Any instance of a StarbucksEmployee can respond to any number of
methods, many of which are downright silly. Who in their right mind, for
example, would request the MakeIcedWhiteChocolateMocha method? I
mean, really!

Component instances are physically separated from those with whom they
are interacting. Larry inhabits his side of the counter and I inhabit mine.
In
the software world, a side of the counter corresponds to a process. When I
make a request of a component instance, I am usually doing so from
outside the process in which that instance lives.

An object is, strictly speaking, an instance of a class. A class is an
object-
oriented programming concept, not a component-programming concept.
While objects, like components, are blobs of software, they are typically
very small, fine grained blobs, and they always live in the same process
(the same side of the counter) as whomever, or whatever, they are
interacting with.

Component and object technologies are therefore quite different from each
other. The former is a packaging and distribution technology, focusing on
what a component can do. The latter is an implementation technology,
focusing on how a component works. A component may or may not be
implemented with objects, and an object-oriented piece of software may or
may not be packaged and distributed with components.

It is critical to keep the difference between packaging and implementation
technologies in mind, since it dictates very different design strategies for
the two types of systems.

The distributed nature of a component, for example, dictates that you
design a small number of methods each of which take a large number of
parameters. The in-process and data centric nature of an object, on the
other hand, dictates a large number of methods, each taking very few
parameters. Quite the opposite. A good object design is invariably a
disastrous component design, and visa versa.

It is easy to confuse components and objects. The component/object
vendors tend to be very loose with their terminology. Microsoft, for
example, sometimes uses the word "object" to mean an instance of a class,
sometimes to mean an instance of a component, sometimes to mean a
class, and sometimes to mean a surrogate (an implementation detail of the
distribution mechanism for components). The word "method" is used often
used to refer to the operation of either an object or a component. It is
often
maddeningly difficult to figure out what is meant in a given context.

But the confusion between objects and component instances goes beyond
just the linguistic and well into the technical. A good example of the
technical blurring of objects and components occurs with Visual Basic.

Visual Basic can be used either as an object-oriented programming
language (sans behavioral inheritance) or as a COM+ component
packaging language (COM+ is the Microsoft middle tier component
packaging and distribution technology). Unfortunately, you can't tell by
looking at Visual Basic code whether you are looking at a component
package or an object implementation.

Let's consider a dog that barks. Here is the Visual Basic code for a dog's
bark method that looks up a dog's bark (via another component/object(?))
and returns it:

Public Function bark(ByVal personName As String) As String
   Dim myData As DataComponent.DogData
   Dim myBark As String
   Set myData = CreateObject("DataComponent.DogData")
   myData.readDogData personName, myBark
   bark = myBark
   Set myData = Nothing
End Function

Is this an object level method or a component level method? You can't tell!
It could be either.

The inability to differentiate between a component and an object is not
limited to Microsoft's Visual Basic. Similar problems occur with Sun's
Java language.

This confusion causes tremendous problems in the middle tier, probably
more than any other single cause. It is especially a problem for object-
oriented programmers who tend to design their components using object-
oriented design methodology. Components that have been designed with
an object methodology usually have the following problems:

- The component methods are too fine grained and therefore perform
poorly.
- The component methods do not deal with state properly and therefore do
not scale.
- The component methods improperly line up with transaction boundaries
and therefore are not reusable.
- The component implementations use a database-centric security system
and therefore make inefficient use of database connections.

Any one of these is a serious design flaw for a middle tier component.
Unfortunately,  most "object-oriented" components have all four of these
problems.

This is not to say that object-oriented technology is bad. It is just to say
that it is different from and orthogonal to component technology. One is
for implementing algorithms. The other is for packaging and distributing
software. And it is critical that you not mix them up. If you do, the next
time you order your Doppio, you may find yourself staring at Larry's
duodenum. And I guarantee you, at 7:00 in the morning, that will not be a
pretty sight.

- Roger Sessions
June 20, 2000
Austin, Texas

***************************************************
UPCOMING PUBLIC SEMINARS WITH ROGER SESSIONS
Vancouver, Seattle, Burbank, Boston, Washington DC, New York City,
Toronto, Dallas, Denver, Philadelphia, Hartford, Rochester, Sydney,
Melbourne

The Roger Sessions Seminar, "COM+ and the Middle Tier", is once again
on the road. This class is perfect for managers, executives, and developers
needing an overview of Microsoft's middle tier technologies and how these
technologies compare to those of the competition. This class covers the
following topics critical to web commerce:

- Why client/server architectures do not scale
- Migration from client/server to three-tier architectures
- Component Oriented Middleware (COMWare): The infrastructure that
holds the middle tier together
- The COM+ component runtime environment
- Measuring scalability
- Dependencies between state and scalability
- Relationship between transactional boundaries and methods
- New techniques for managing transactional boundaries
- Middle tier security vs. Database security
- The two dimensions of middle tier security
- Using asynchronous methods and transactional implications
- The two-phase commit protocol and how it ties together databases and
message queues
- Using clusters to provide scalability and high reliability
- Integrating legacy back end products
- The weaknesses in the COM+ architecture
- How Microsoft's COM+ compares to Sun's Enterprise Java Beans 1.1
- How Microsoft's COM+ compares to CORBA 3.0

Join Roger at one of these public classes:

- July 17 Vancouver BC
- July 18 Seattle
- July 20 Burbank
- August 21 Boston
- August 22 Washington DC
- August 24 New York City
- August 25 Toronto Canada
- September 12, Dallas TX
- September 13, Denver CO
- October 10, Philadelphia PA
- October 11, Hartford CT
- October 13, Rochester NY
- December 4, Sydney Australia
- December 6, Melbourne Australia

Seats are $550 each, and space is limited to 25 students per class. Write
[e-mail] for more information, or visit the ObjectWatch
web site (www.objectwatch.com). And of course, we can always arrange
private classes (either full day or half day versions) for your company.
Again, Janet is your source of scheduling.

This class has been taught to over 30,000 students in over 100 cities in
over 20 countries. The feedback has been tremendously positive. Some of
the comments we have received are:

"Very well presented. Excellent coverage of issues. Roger has compiled a
concise presentation. Very good seminar. Thank you very much."

"Roger provided an extremely well rounded and lucid explanation of the
background and issues. Excellent presenter."

"The structure of the presentation was excellent with the background and
history of components and TPM [Transaction Processing Monitors]. A
very informative talk which hit the mark for me."

"Thank you for your dissertation on the options available to us in the
component oriented middleware market, last week Thursday in
Auckland. I enjoyed your presentation and found your knowledge
impressive, your vision refreshing and your humor and enthusiasm
infectious. A jolly good show with practical substance."

And watch for this new class coming soon from ObjectWatch: Hands on
Web Commerce Development. A five day hands-on lab class exploring the
Microsoft Windows DNA 2000 commerce platform. This class is an
independent assessment of the Microsoft platform from the world's leading
expert on the Middle Tier. You will learn what is good about Windows
DNA, what problems exist with the platform, and how to how to plan and
organize your browser-based web commerce system around these critical
Windows DNA technologies: Internet Information Service, Visual
InterDev, Active Server Pages, Visual Basic, COM+, Active Data Objects,
and SQLServer 7.0.

***************************************************
NEW AND NOTEWORTHY WEB SITES:
The ServerSide.com

We are always interested in web sites, books, and articles that focus on
issues relevant to the middle tier. We feel it is particularly useful to our
readers to point out resources for perspectives that differ from our own. In
this spirit, we recommend you visit http://www.ServerSide.com. This is a
site that gives the Java slant to the middle tier. While we don't agree with
all of the conclusions on this web site, it is definitely a well designed
and
well thought out site. And because it is not directly affiliated with any of
the Java vendors, it takes a more objective perspective on examining
middle tier issues.
***************************************************
LETTERS FROM VERY IMPORTANT PEOPLE: PAUL HARMON
It is always the policy of the ObjectWatch Newsletter to offer opportunities
to respond to those we criticize. We are not sure that this month's
Quotation of the Month is a criticism, but to err on the side of caution, we
sent Paul Harmon an early copy of this newsletter and offered him an
opportunity to respond. The following is his response, printed in its
entirety and without editing.
...
Roger,
You say in your note that "I'm not sure this quotation actually
qualifies as a 'criticism."  I can't see that it does.  It represents my
current take on CCM and the component market, and I stand by it.   Like
all quotes, its taken from a context that says a lot more and that
qualifies the paragraph in various ways.  I hope your readers will check
the IBM Developers Site, which you list, and read the article that this
quote is taken from.  Thanks for the opportunity to comment.
- Paul Harmon
***************************************************
GREAT STARTUP OPPORTUNITY FOR INSTRUCTORS AT
OBJECTWATCH

We would like to tell you about some great startup opportunities for some
great Instructors at ObjectWatch, the leading company in the middle tier.
Please check out our web site (www.objectwatch.com) for all the details!
***************************************************
ABOUT OBJECTWATCH

ObjectWatch specializes in teaching how to write effective web commerce
applications built on distributed components and Component Oriented
Middleware (COMWare).  Roger Sessions designs all of the ObjectWatch
classes. He has many years of close association with CORBA, Java, and
Microsoft technologies.

Roger's most recent book is "COM+ and the Battle for the Middle Tier",
published by John Wiley & Sons. This book is a introduction to COMWare
technologies. It discusses the COM+ COMWare platform and compares it
to the other industry COMWare standards (EJB and CORBA). This book
can be ordered at
http://www.amazon.com/exec/obidos/ASIN/0471317179/objectwatchA
***************************************************
Recent issues of this newsletter are available at
http://www.objectwatch.com

#27: Greg Pfister responds to ObjectWatch Newsletter #26
#26: Measuring Scalability
#25: SOAP
#24: The Sun White Papers
#23: Why I Don't Drive a Lamborghini
#22: The Best Feature of COM+
#21: Anne Thomas Responds to Newsletter #20
#20: A Critical Look at EJB 1.1 (Part 1/5)
#20a: A Critical Look at EJB 1.1 (Part 2/5)
#20b: A Critical Look at EJB 1.1 (Part 3/5)
#20c: A Critical Look at EJB 1.1 (Part 4/5)
#20d: A Critical Look at EJB 1.1 (Part 5/5)
***************************************************
Legal Notices:
The ObjectWatch Newsletter does not accept outside advertising or rent
out its subscription list.

This newsletter is Copyright (c) 2000 by ObjectWatch, Inc., Austin, Texas.
All rights are reserved, except that it may be freely redistributed provided
that it is redistributed in its entirety, and that absolutely no changes are
made in any way, including the removal of these legal notices.

ObjectWatch is a registered trademark (r) of ObjectWatch, Inc., Austin,
Texas. All other trademarks are owned by their respective companies.
***************************************************