From: Conrad Schneiker Date: 2000-06-25T02:19:47-05:00 Subject: [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 sub@objectwatch.com saying: subscribe your-name,your-email For example, subscribe Roger Sessions,roger@objectwatch.com To unsubscribe, send mail to sub@objectwatch.com 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 roger@objectwatch.com. *************************************************** 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 janet@objectwatch.com 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. ***************************************************