Stateless Vs Stateful Model -> COM Vs CORBA?

[Jinny Uppal <juppal01@cs.fiu.edu>]

In the last presentation of mine(ORB Products-A Comparative Analysis), i
had raised a question about the significance of choosing a stateful model
(as in CORBA) or a stateless model (COM/DCOM). I think in the following
article I have a pretty good answer. Roger Sessions worked for IBM for
a long time(11 yrs)  and is the achitect of the Persistant Object Service.
(which was subsequently declared unimplementable by most vendors. In fact
the Persistant State Service is being worked on, to replace POS I guess.)
He subsequently moved to the Microsoft. You might guess the reason, but
his articles always provoke pro-CORBA experts. His other articles can be
found at www.objectwatch.com. I must say, they are very interesting.

Jinny.
PS:You must read Scott Adams reply, that follows Roger Session's. It
reveals more about the differences between the two models.

------------------------------------------------------------------------------
 - Roger Sessions
***************************************************
MAIN STORY: MATTERS OF STATE
When I worked at IBM Austin, my desk was a mess. Not any more. Now 
when I leave my desk at the ObjectWatch, Inc. headquarters, I don't 
leave so much as a pencil. Even if stepping out for only an hour, I leave 
that desk spotless.

It's not that I have turned over a new leaf. My wife will gladly tell that I 
still leave things everywhere. After 20 years of marriage, I have been 
somewhat domesticated, but my natural inclination is still to pick it up 
tomorrow. Or the next day. Or whenever. 

So what has happened between IBM and ObjectWatch to make my desk 
the clean machine of Austin? It has nothing to do with a change in me. It 
doesn't even have much to do with the change in my desk. It has to do 
with a change in my desk algorithm. Which, by the way, has changed not 
only my ideas about desks, but also my ideas about the scalability of 
distributed components. But we are getting ahead of the story.  Let me 
first tell you what I have learned about desks.

When I worked at IBM Austin, I had my very own desk in a very large 
building filled with very large number of very similar desks. Each one of 
those desks had one and only one individual assigned to that desk. Since 
a large number of individuals worked in that building (about 500), a 
large number of desks were needed. Hence the building had to be very 
large. Desks take up space.

The building I work in today also hosts about 500 people. But it is very 
small. In fact, I would say that it would get crowded if more than 50 
people showed up at the same time. Fortunately they rarely do.

In order to understand this system, you need to know a little about how 
ObjectWatch works. First of all, ObjectWatch is lean and mean. We only 
have two employees: Janet and me. Janet is lean. I am mean. We are too 
cheap to rent a fancy shmancy office building like IBM. So we use a 
virtual office. We rarely see each other, but we are in constant 
communication through either email, cell phones, or both. 

When we do meet, we do so in the world wide headquarters of 
ObjectWatch, Inc, namely, the Starbucks at 183 and Lakecreek in Austin, 
Texas. We grab whatever table is available for as long as we need it. 
While we are using that table, we have it cluttered to the hilt. My laptop, 
Janet's palm top, note pads, cell phones, my Dopio Macchiato, Janet's 
Mocha Freeze, a few pastries. You wouldn't think you could get so much 
junk on one little table at Starbucks.

When we are done, we are gone. My laptop is back in my backpack. 
Janet's palm top is in her purse. Our Dopio Macchiato, Mocha Freeze, 
and pastries are all enjoying their new homes. Not a trace is left behind. 
Two minutes after we leave, that same table may be occupied by another 
world wide corporate headquarters making their own plans for global 
conquest.

So what is the difference between IBM, which requires a six story 
building to house 500 people, and Starbucks, which requires less than 
1000 square feet to house the same number? I assure you, it has nothing 
to do with the workload of the people. At least as much work is 
accomplished each day at Starbucks as is in my old building at IBM. It 
also has nothing to do with the amount of time people actually spent at 
their desks. There were many days at IBM when I spent less time at my 
desk than I spend today working at Starbucks.

The difference has to do with desk policy. IBM let me keep whatever I 
want on my desk and as much as I wanted. This had two important 
results. First, when I needed a desk, there was only one that would 
suffice. Second, when somebody else needed a desk, they couldn't use 
mine, because it was filled with my stuff, even if I was off on a two week 
vacation. My desk was a permanent monument to the current state of my 
work in progress. 

Starbucks does not put up with this. They follow the clean sweep 
algorithm. When I leave Starbucks, anything I leave on "my" desk 
immediately goes in the garbage. Starbucks doesn't distinguish between 
muffins and manuscripts, as happy to sweep away the leftover crumbs 
and the detailed notes for my next book. I'm gone, it's gone. If I want to 
save the state of my work in progress at Starbucks, I either carry it with 
me or I find another home for it.

The difference between IBM and Starbucks therefore comes down to a 
matter of state. Of more specifically, how state is managed. 

Because the desks at IBM maintain work state, they are necessarily hard 
wired to specific individuals. And because they are hard wired, IBM 
needs a building large enough to house all of the desks of all of the 
individuals that work at IBM, regardless of how many (or how few) are 
working at any given moment.

Because the desks at Starbucks do not maintain work state, they can 
freely be assigned to the next person that walks in the door. Because they 
can be freely assigned, Starbucks only needs a building large enough to 
house all of the individuals that will work at Starbucks at any one time, 
which, like IBM, is a small fraction of the total individuals who actually 
work there.

Notice that this does say that there is there is a "state" of my workload at 
IBM, and not at Starbucks. When I leave Starbucks, my backpack is 
filled with the state of my workload. It is only to say that at Starbucks, 
the state doesn't get left on the desk.  Or if it does, it won't be there when 
I return.

Let's say that the person who uses a desk is called a desk client. And let's 
make the following assumptions:
1. Both Starbucks and IBM need to service 500 desk clients.
2. At both Starbucks and IBM, only 50 (10 percent) are actually 
physically using their desk at any one time.
3. A desk takes up 25 square feet of space.
4. Building costs in Austin are about $100 per square foot.

The cost per desk is the same for both Starbucks and IBM: $2,500 (1 
desk X 25 square feet per desk X $100 per square foot). But at Starbucks, 
that $2,500 will house 10 clients and the cost per client is only $250. At 
IBM, that $2,500 will house exactly one client, so the cost per client is 
the full $2,500. So IBM will need a building costing $1,250,000 for its 
500 clients, while Starbucks will make due with only $125,000.

As you can see, Starbucks is able to use their building funds much more 
efficiently than can IBM. In general, the increase in efficiency is given 
by these straightforward formulae:

N (increase in efficiency)
M (fraction of actual desk usage)
N = 1/M

The difference in the number of clients that can be supported is 
Cs (Number of clients supported in Starbucks model)
Ci (Number of clients supported in IBM model)
Cs = Ci X N (from previous equation)

So if a typical client actually uses a desk 1/4 of the time, then M is 1/4 
and N is 4, so Starbucks is 4 times as efficient. If IBM can support 1000 
clients, then for the same price, Starbucks can support 4000 clients.

What exactly makes Starbucks run so much more efficiently than IBM? 
Two things. One we have already discussed, and that is the clean desk 
policy: leave nothing on the desk, expect nothing on it when you return. 
But one other thing is required: an infrastructure that efficiently allocates 
desks. 

Actually, if the truth be known, IBM also had a clean desk policy. At 
IBM, you could receive the horrid "security violation" for leaving stuff 
on your desk. I once even received a "security violation" for locking the 
door to my office. Why, you might ask, is locking your door a security 
violation? Because then Security can't get into your office to see if there 
is stuff on your desk!

However I quickly discovered that nobody cared about security 
violations. So I just left stuff on my desk, and let the security violations 
pile up. In fact, some of the stuff on my desk was old security violations. 
The bottom line was that I knew that even though IBM had a clean desk 
policy, it had no infrastructure to allocate desks. Whereas Starbucks does 
have such a structure. Their policy is simple: sit down, anyplace you 
want, anything you see, toss in the garbage. That is a serious policy. Not 
to be toyed with.

In situations where M (the fraction of time client uses desk) gets very 
small, the difference between Cs (the number of clients supportable in 
the Starbucks model) and Ci (the number of clients supportable in the 
IBM model) can become huge.

One example of such a situation is in Distributed Component Systems 
(DCS). In fact, this basic model has a huge impact on the scalability of 
such systems. Let's consider the architecture of a typical DCS.

A DCS is usually three tiers. The client tier consists of machines running 
applications that are hooked up, directly or indirectly, to human beings. 
The middle tier consists of business logic that is packaged using 
component technology, such as OMG's CORBA or Microsoft's 
COM/DCOM.  The third tier consists of database machines, machines 
that are extremely competent in storing and managing the flow of data.

The client machine is going to be acquiring the information needed to 
process a business request. Once that request is ready, it sends that 
request down to a component instance living on the middle tier. The 
component logic then processes the request and returns the resulting 
information back to the client.

I usually think of components as like software gnomes. A certain type of 
software gnomes can do things for you. For example, a credit card 
management gnome can process credit card requests. You find a 
particular credit card management gnome, say Ralph, and he will help 
you with your credit card processing.

But Ralph can't process your request until you have your information 
ready. If it takes you, say, two minutes to collect your information and 
1.2 seconds for Ralph to process your request, then you are using Ralph 
1 per cent of the time you are actually working. You can see that the 
relationship between a client and Ralph is very similar to the relationship 
between a desk client and a desk.

Now the cost of the middle tier is going to be determined by how many 
of Ralph (and his friends) we need to have running at any one time. How 
many will we need to process, say, 1000 clients? Well, that depends on 
whether we are using the Starbucks model or the IBM model. 

If we are using the IBM model, then each client needs a dedicated Ralph, 
even though Ralph is only being used 1 per cent of the time. If we are 
using the Starbucks model, each client is associated with a Ralph only 
while actually using Ralph

What will determine which of these two models (IBM or Starbucks) we 
are using for Ralph? Two things. The first is how we are dealing with 
work state. If we allow clients to store information in Ralph (like I stored 
stuff on my IBM desk), then we are going to need 1000 Ralph 
lookalikes, and a very large expensive middle tier machine. If we don't 
allow clients to store information in Ralph (like I don't store stuff on my 
Starbucks desk) then we only need 10 Ralph lookalikes, and a machine 
that is a fraction of the cost (.01, to be exact) of the IBM version.

However the banishment of state from Ralph is not enough to achieve the 
Starbucks model. The second thing we need is an underlying desk 
allocation algorithm that takes advantage of Ralph's statelessness. On the 
middle tier, this means a component runtime environment that allocates 
component instances (like Ralph) based on need, and then reclaims them 
as soon as the need has been fulfilled. There are several algorithms used 
by component runtime environments to do this instance management. 
We will discuss them in a future version of this newsletter. For now, it 
will suffice to say that all of these algorithms depend on the agreement 
that when you are finished asking Ralph to do something, you don't leave 
your work state inside him.

We often use the word "stateless" to describe how we work with Ralph. 
This word is meant to indicate that we don't store any state inside Ralph. 
However the word causes a lot of confusion. For example, Victor Rini, a 
reader of this newsletter, recently sent me a column called Thinking 
Objectively, by Scott Ambler in the August 1998 issue Software 
Developer. Scott said, "Microsoft's statements about DCOM's support for 
'stateless objects' aside, DCOM has nothing to do with objects (every 
pro-Microsoft techie who I have ever pressed on this issue has 
acknowledged this fact)."

Scott's statement is typical of the confusion about this issue. Scott 
believes that because Microsoft's component instances are stateless (in 
the sense that Starbucks tables are also stateless) that these instances are 
unable to deal with state. This, of course, is completely wrong. Just as I 
can work with piles of junk at my Starbucks table, Ralph can work with 
any state he needs. It just means that when Ralph is finished processing 
my request, that state gets stored someplace else. 

There are many possibilities as to where that state should be stored when 
Ralph is finished. The most likely place to store that state is in a back-
end database. After all, that is the whole purpose of the data tier 
(remember the data tier?). Databases are the only technology we know of 
that can manage state correctly in a shared, high throughput, 
transactional environment. 

To say, as Scott does, that "DCOM has nothing to do with objects" is to 
take the most naive view possible as to what is meant by the word 
"object". By his definition, the word "object" is necessarily inconsistent 
with any kind of middle tier efficiency. If we have to give up middle tier 
efficiency to support objects, I assure you, objects have as much future as 
the black and white television.

This issue of state and middle tier efficiency is a general issue, not an 
issue specific to Microsoft. Every component runtime environment that 
supports middle tier efficiency has the same requirements as does 
Microsoft's. For example, BEA's M3 product (until recently called 
Iceberg) places exactly the same restrictions on its component instances, 
despite that fact that its component model is based on CORBA, not 
COM/DCOM. Similarly for IBM's Component Broker, another CORBA 
derivative. Similarly for Sun's Enterprise Java Beans. According to 
Scott's definition, none of these are object systems, a conclusion that will 
surely surprise these vendors, none of whom agree on anything other 
than that all of their systems are based on objects.

I compared the major component runtime environments in my last issue 
(http://www.objectwatch.com/issue12.htm), so I won't do that again here. 
However I must point out that another of Scott's mistakes is that he 
doesn't include Microsoft's MTS, MSCS, or MSMQ products in his 
analysis. To judge COM and DCOM without looking at Microsoft's 
entire middle tier architecture is like judging a house based only on the 
dirt on which it is built.

So if you are planning a large, distributed, component based system, you 
are going to have to plan for middle tier scalability. The starting place for 
this planning is how you are going to manage the state of your 
components. This will make or break the scalability of your application 
as a whole. So plan your management of state very carefully. I even 
know a good place to do this planning: the Starbucks in Austin at 183 
and Lakecreek. Walk in, grab a Dopio Macchiato, and get to work. Just 
don't use my desk.

- Roger Sessions
Austin, Texas
July 19, 1998

***************************************************
LETTERS FROM VERY IMPORTANT PEOPLE: SCOTT AMBLER 
REPLIES
In the interest of fairness, I offered Scott Ambler an opportunity to 
respond to my criticism of his article. He sent the following reply, which 
I am reprinting in it's entirety and without editing.

Scott Ambler replies:
I don't think there's any confusion to the issue -- Microsoft is doing a 
marketing snowjob and has redefined the term object to meet its own 
current needs.  Please feel free to look into the definition of object by any 
respected author in the OO industry (names such as Grady Booch, James 
Rumbaugh, Peter Coad, Ivar Jacobson, and Steve Mellor to name a few 
come to mind) who for some strange reason point out that objects 
encapsulate both state and behavior.  Forgive me for not detecting the 
naivete of some of the most respected people in the industry when they 
included state in their definition of object.  I don't know what I was 
thinking about.  Correct me if I'm wrong, but doesn't COM+ talk about 
good things like objects that have both state and behavior?  I can't 
believe how naive that is!  Sort of makes you wonder why Microsoft 
would plan to migrate to something like that, doesn't it?

I have no problem with the fact that you need to store the state of objects 
in some sort of persistence mechanism, such as a flat file or a relational 
database.  You might not know this but for many years I've been saying 
that it's okay to use an RDB on the back end, long before it became 
fashionable to do so (a fairly recent occurrence I might add).  Feel free to 
download some of the papers, posted at 
http://www.ambysoft.com/onlineWritings.html, on this and related OO 
development subjects.  The problem that I have is when I'm told that the 
only way to do things is to only distribute behavior and then pass data 
(state) back and forth as parameters.  Sound like the current DCOM 
strategy?  You bet.  There are a lot of applications out there where it 
makes sense to load a bunch of objects, work with them for an 
indeterminent amount of time outside of the scope of a transaction, and 
then persist them when you're done.  Yes, there's some concurrency 
issues (there's always concurrency issues) but you know what, one of 
several ways to build such a system is to naively use objects that have 
both state and behavior.

As far as middle-tier efficiency goes, until you know my requirements 
for the applications I'm building, it would be incredibly naive to claim 
what architecture is efficient for my situation and what isn't.  Yes, for 
some applications the transaction-processing model supported by MTS is 
the perfect solution, for other applications it isn't.  The TP monitor 
approach to efficiency is one way to go, but it is only one of many.  As 
far as MSMQ goes, frankly I think it addresses one of the biggest 
weaknesses of CORBA, namely the implicit assumption of continuous 
connectivity.  The ability to queue messages is a good and virtuous thing 
in my book.

If you wish to support Microsoft's concept of "stateless objects" as being 
objects in the OO sense, please feel free to do so.  Myself, I know 
marketing BS when I hear it.  DCOM is a distributed behavior strategy, 
not a distributed object strategy, which is fine for a lot of applications.  
Call it what it is and use it where appropriate.

With respect to my article, you might want to read the entire thing.  In it I 
present one approach to protecting yourself from the CORBA vs. DCOM 
debate.  One of the problems with the approach is that although it looks 
good on paper, in the same manner that everything works on marketing 
slides, in reality it proves challenging to implement due to the impedance 
mismatch between the distributed-behavior paradigm of DCOM and the 
distributed-object paradigm of CORBA.  I can't help but think that if 
both approaches were based on objects then it wouldn't be as difficult to 
substitute one for the other.  I guess it's simply a matter of state.  :-)

- Scott
***************************************************
BOOK REVIEW: IN SEARCH OF CLUSTERS BY GREG F. PFISTER
Several months ago I had a wonderful lunch with Greg Pfister at which 
we talked about everything clustered. I have been meaning to turn my 
notes from that lunch into an article for this newsletter, but time and 
other issues keep pushing it back. I had planned to review his new book 
at that time, but I have decided to wait no longer to put out the word on 
this remarkable work.

Greg is the King of Clusters. He has a passion for his subject and an 
incredible depth of knowledge. He is also one of the best technical 
writers publishing today. Even if you have no interest in clusters, you 
may find his writing style so engaging that you will be unable to put 
down this book. 

The first edition of this book was a huge influence on Microsoft's MSCS 
product. The early code name for MSCS was Wolfpack, named in honor 
of Greg's first edition. Greg's cover showed a multi-headed dog being 
attacked by a dog pack, an allegory for the battle between clusters of low 
level machines and symmetrical multi-processors. Microsoft didn't want 
to use the code name "Dogpack", so they reinterpreted the picture as a 
Wolfpack.

The second edition has been significantly reworked and updated. The 
book is split into four parts. Part 1 is an overview of cluster issues. Part 2 
is about hardware issues. Part 3 is about software issues. Part 4 is about 
systems level issues. The book is almost 600 pages long, a 50% increase 
over the first volume.

This book gives a great overview of the problems involved in cluster 
technology. "Clusters" refer to the ability of many small machines to 
perform together as what Greg calls a Single System Image. In other 
words, how a bunch of machines can act to the user as one machine. 
When one machine in the cluster becomes overworked, its workload is 
off loaded to the other machines in the cluster, without any intervention 
on the part of an administrator. As one machine goes down, the rest of 
the machines take over. This gives us the ability to create very high 
availability and very high throughput systems based on very inexpensive 
machines. Is this really possible? Greg says the technical problems are 
difficult. And he lists them all, with extensive descriptions of the 
algorithms and/or hardware configurations known to solve them. 

A word of warning: This is a technical book. There is more detail in here 
than many will want. But it is a very well written technical book, and 
Greg's style makes a complex topic accessible to many whom would 
otherwise be lost in a sea of acronyms. If you are interested in clusters, 
this book is an absolute must read. And even if you aren't, but just like to 
see technical writing at it's best, you will find this book irresistible.

In Search of Clusters can be purchased through the ObjectWatch on-line 
Bookstore (http://www.objectwatch.com/bookstor.htm), or through many 
bookstores with good computer sections. It's ISBN is 0-13-899709-8, and 
it's suggested price is $44.95.
***************************************************
BRIEFLY NOTED: THE OBJECT NEWS SITE
Keeping up with the never ending torrent of information in the object 
world is very difficult. One web site that really makes a difference is the 
Object News Site, maintained by Dion Hinchcliffe and Paul Evitts. This 
site, with its daily updates, is the New York Times of the object world. If 
it's about objects, it's covered on this site. They keep their own politics 
and religion out of it. They cover CORBA, Microsoft, and you name it in 
a remarkably impartial way. If you haven't been here, I highly 
recommend a visit. These two guys are putting a lot of work into making 
our lives easier, and they deserve our support. You can find their site at 
http://www.objectnews.com
***************************************************
UPCOMING PUBLIC SPEAKING ENGAGEMENTS OF ROGER 
SESSIONS
It's always a special treat to have ObjectWatch Newsletter readers join 
me at public speaking engagements. Some of my upcoming engagements 
include the following:

September 8 Austin, Texas. The Austin Forum of Object Oriented 
Technology (AFOOT). Topic: COM, DCOM, And The Microsoft 
Distributed  Component Architecture. For more information, see 
http://www.prismnet.com/~afoot/

September 16-19 Washington, D.C. Keynote address at the 
Object/Relational Summit. Topic: The Middle Tier: Where Objects And 
TPMs Meet. For more information, see 
http://www.dbsummit.com/or/98home.htm

November 3-5 Finland. Keynote address at Object Computing Europe-98 
on The Marriage Between Components And TPMs, and tutorial on 
COM, DCOM, And The Microsoft Distributed  Component Architecture. 
For more information, see http://www.tieturi.fi/oce98/
***************************************************
UPCOMING PUBLIC CLASSES OF ROGER SESSIONS
We are preparing our fall schedule for our public classes. We try to give 
our newsletter readers advanced notice, so that they get first chance at 
seating. Attendance is limited to 25. Our last public class completely sold 
out within five days of announcement, so if you are interested, please act 
quickly. And if you are a public school teacher or if you know a public 
school teacher, please see the information below about free scholarships. 
For more information on any of these classes, drop a note to Janet 
(janet@objectwatch.com). Our current schedule plan is as follows:
Aug. 10 - Toronto
Aug. 19 - Austin
Sept. 10 - Seattle
Sept. 14 - Boston
Sept. 17 - Washington, D.C.
Oct. 1 - Oct 9 - Nordic countries

Brief Class Description:
COM, DCOM, AND THE MICROSOFT DISTRIBUTED 
COMPONENT ARCHITECTURE 
(ONE DAY, LEVEL: INTERMEDIATE)

Commerce systems are very demanding. The most successful commerce 
systems have historically been based on complex Transaction Processing 
Monitors and expensive main frame computers. They have been difficult 
to program and expensive to run. But this is changing.

Microsoft has introduced a revolutionary component based architecture 
for creating commerce systems. For the first time we are able to build 
highly scalable, high throughput, three-tier transactional commerce 
systems using only basic programming skills. And we are able to run 
these commerce systems on inexpensive NT servers and plug them right 
into the Internet.

The most important part of Microsoft's architecture we call MDCA 
(Microsoft Distributed Component Architecture). This is the architecture 
that supports the middle tier. It is this tier that runs the business logic and 
controls security, transactions, and scalability. It is this tier that 
determines the success or failure of modern commerce applications. 

This class is for people who are trying to understand the Big Six 
technologies that make up MDCA. These technologies are:

1. COM (The underlying component model)
2. DCOM (The underlying distribution model)
3. MTS (Microsoft Transaction Server)
4. MSMQ (Microsoft Message Queue Server, aka Falcon)
5. MS-DTC (Microsoft Distributed Transaction Coordinator)
6. MSCS (Microsoft Cluster Server, aka Wolfpack)

In order to understand Microsoft's vision for commerce applications, it is 
necessary to understand these six technologies, how they fit together, and 
how they relate to Microsoft’s overall DNA (Distributed interNet 
Applications) strategy. These MDCA technologies cover a wide range of 
material, from distributed object architectures to distributed two-phase 
commit to object pooling. This class is intended to make these 
technologies accessible to a wide audience. We use simple everyday 
analogies to describe basic issues in distributed programming and to 
explore the algorithms that make commerce programming possible. 

This class gives an overview of this visionary architecture and how it 
compares to the architectures based on CORBA and Enterprise Java 
Beans. The class is intended for programmers, analysts, and managers 
needing an unbiased perspective on the Microsoft's Distributed 
Component Architecture and how it can support their overall business 
strategy.

FULL SCHOLARSHIPS FOR PUBLIC SCHOOL TEACHERS
ObjectWatch believes that nothing is more important to the future of our 
country than our children. We believe that public school teachers are the 
unsung heroes, the transmitters of knowledge to our next generation. We 
want to support our teachers and help them in their efforts to teach 
current and relevant technology. Therefore we are proud to announce an 
experimental full scholarship program for public school teachers at all 
ObjectWatch public classes.

Here is the deal. We will reserve two seats at all ObjectWatch public 
classes for public school teachers. There will be no charge for these 
seats, and teachers will be full participants in the class. We will also 
provide to these teachers, at no charge, a copy of Roger Sessions' book 
"COM and DCOM; Microsoft's Vision for Distributed Objects".

 If you are a teacher, you are eligible for these seats if you meet the 
following qualifications:
1. You are a full time teacher in a public high school.
2. You teach in the city in which the public class is being offered.
3. You teach at least one programming class.
4. You have knowledge of object-oriented programming.
5. If demand exceeds supply for these seats, we will give priority to 
teachers in inner city schools.

We are trying out this program for the next several months, and we 
expect to extend it thereafter. If you are interested and qualify for this 
program, please write to Janet (janet@objectwatch.com) and let her 
know of your interest in participating. We will expect you to provide 
proof of your eligibility upon your acceptance.

WE APPEAL TO OUR READERS TO HELP US MAKE THIS 
PROGRAM KNOWN TO TEACHERS IN YOUR AREA.

We encourage other computer training organizations to join us in 
supporting our public school teachers and letting them know, in this very 
concrete way, how much we care about them and their work.
***************************************************
ABOUT OBJECTWATCH
ObjectWatch specializes in middle tier architectures, with emphasis in 
the architecture we call MDCA, (Microsoft's Distributed Component 
Architecture). This architecture includes six key technologies: COM; 
DCOM; MTS, DTC, MSMQ, and MSCS. These technologies are the 
basic building blocks needed to create highly scalable, component 
oriented applications using NT as the middle tier. 

We offer public and private classes describing these middle tier 
technologies. If you are starting to create multi tier applications around 
NT as a middle tier, evaluating NT as a middle tier environment, or 
trying to decide whether your company should use CORBA or MDCA 
for its distributed architecture, this class will prove invaluable.

Roger Sessions teaches all of the ObjectWatch classes. He is the author 
of COM and DCOM; Microsoft's Vision for Distributed Objects, 
published by John Wiley & Sons. This book is a gentle introduction to 
the three tier scalable distributed object architecture of Microsoft. This 
book can be purchased at your local computer book store, or on-line at 
http://www.objectwatch.com/bookstor.htm.

Roger Sessions is the President of ObjectWatch, Inc. He is the author of 
four books and dozens of articles. He has extensive experience with both 
CORBA and Microsoft middle tier architectures. He is a frequent 
conference speaker on middle tier architecture. Visit the ObjectWatch 
web page at http://www.objectwatch.com or contact Roger Sessions at 
roger@objectwatch.com for details on how ObjectWatch can help your 
corporation succeed with Microsoft's distributed object technologies.
***************************************************
Recent issues of this newsletter are available at 
http://www.objectwatch.com
# 12: CORBA vs. EJB vs. MDCA: The Battle for the Middle Tier
# 11: Life in the Middle Tier
# 10: Roger vs. The 850 Ton Gorilla
# 9: Scalability in Three-Tier Component Systems
#8: Reflections from the Colorado Software Summit 1997
#7: Java - The Microsoft Perspective
***************************************************
Legal Notices:

The ObjectWatch Newsletter does not accept advertising or rent out its 
subscription list.

This newsletter is Copyright (c) 1998 by ObjectWatch, Inc., Austin, 
Texas. 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.
***************************************************




To unsubscribe send a note to majordomo@cs.fiu.edu with the body of the message
being: unsubscribe cadse-orb