|
ObjectWatch Newsletter # 41 Feel free to forward this newsletter, but don't make any changes. Thanks. There are now over 17,000 subscribers to this newsletter and over 68,000 readers! For your own free email subscription, send mail to sub@objectwatch.com saying: For example, To unsubscribe, send mail to sub@objectwatch.com
saying CONTENTS
QUOTATION OF THE MONTH:ANOTHER INDUSTRY MISUNDERSTANDING BY ROGER SESSIONSWHAT ROGER SESSIONS SAID:"But ultimately, hiding Java Data Objects is no more
satisfying or effective, than hiding Entity Beans. Bad platform APIs
should not be hidden. They should be eliminated. And perhaps they will be.
So far, Java Data Objects is still just a draft proposal. So perhaps it
will never see the light of day. We can at least hope.” WHAT SUN SAID:“It is unfortunate that Roger Sessions has so completely
misunderstood the architecture of J2EE and Java Data Objects, and worse,
makes no attempt to understand the technology before spouting off.” WHAT SUN DID:“Sun Microsystems Inc. has dropped its implementation of
the Java Data Objects specification from its Sun ONE Studio 4, formerly
called Forte for Java 4, and has not announced concrete plans to replace
it, leaving many of its developers in the lurch.” WHO DO YOU THINK WAS RIGHT?The winner of the Quotation of the Month Contest is Jeet
Jagasia who gets a choice of a personally autographed copy of Roger
Sessions's book, "COM+ and the Battle for the Middle Tier", Roger
Sessions's upcoming book, "The Software Fortresses Primer", or the
ObjectWatch BBQ apron. Send in your nominations for Quotation of the Month
to roger@objectwatch.com, and you too can get a personally autographed
book/apron! MAIN ARTICLE:SHOOTOUT AT THE TRANSACTION CORRAL; BTP VERSUS WS-T(There are many acronyms in this article. They are all defined before being used, but they are all also listed alphabetically at the end of the article.) I can’t start my morning without my doppio macchiato, one brown sugar, extra foam. I can only get this from Starbucks. Nobody else in Austin makes an acceptable doppio macchiato. But the Starbucks FOOD is something else. Ok, no beating around the bush, the food stinks. All high fat, high carb, low protein muffins. I need PROTEIN in the morning! El Arroya is right across the street. They make great breakfast tacos. A fine way to start the morning. But they have no idea what a doppio macchiato is. Do you know what goes great with breakfast tacos? Burger King fries! (I know, I was just complaining about high fat, high carb Starbucks muffins, but if you must eat fat, fries are the way to go.) So here is my ideal breakfast: one doppio macchiato from Starbucks, one breakfast taco from El Arroya, and one order of fries from Burger King. I never get my ideal breakfast. The reason is that I am too afraid of what I might end up with. If El Aoyoa is out of breakfast tacos, I could end up with just doppio macchiato and fries. Yech! Or if the Starbucks espresso machine is broken, I could be staring at a breakfast taco and fries but no doppio. I thought of a solution once. Here was my plan. (I go to Starbucks.) You can see the problems with this system. Even if I don’t die of a heart attack or get run over, I still run the risk of one of these fine eating establishments running out of food (Breakfast taco? Sorry, we just closed!) I wish I had a breakfast coordinator. Imagine if there was one person who does nothing but coordinate breakfasts for other people, say Bill. Bill, the breakfast coordinator. Here is how Bill could help me. Instead of starting my breakfast at Starbucks, I start at Bill’s. I tell Bill I am about to order breakfast. Bill doesn’t ask me what I want to order or where. Bill doesn’t care. All Bill does is hands me a ticket. On the ticket, it says two things: “Roger’s Breakfast” and Bill’s phone number. Now I go to Starbucks. I tell them I want a doppio macchiato and hand them the ticket. They call the phone number on the ticket. Bill answers. They have the following conversation: Bill: Hello. Starbucks then makes note of the fact that I ordered a doppio macchiato. They don’t do anything, just note what I ordered. I repeat this scenario at El Arroya and Burger King. Nobody does anything except report in with Bill and make a note of the food I want to order. Then I go back to Bill. I say, “Bill, I want breakfast!” I hand Bill my ticket. Bill sees “Roger’s Breakfast” printed on the ticket. He remembers that three eating establishment have called him and told him they are part of Roger’s Breakfast. He now calls each back in turn and has the following conversation: Bill: Hey, Bill here. About Roger’s Breakfast,
are you still ok with that? Once Bill has called each of the food places and each has told him that it is still ok with Roger’s order, he makes another round of calls. In this round, he has this conversation: Bill: Hey, Bill here. About Roger’s Breakfast,
MAKE it! Then Bill turns to me and says, “Breakfast is served.” I now make one final trip to each of the food joints, this time with the full assurance that my order will be served in full, and that I will end up with one doppio macchiato, one breakfast taco, and one order of fries. Nothing more. Nothing less. Or maybe, not. Because there is at least one other scenario. Let’s say Starbucks has run out of cups. Then the second conversation between Bill and Starbucks would look like this: Bill: Hey, Bill here. About Roger’s Breakfast,
are you still ok with that? Now we have a different ending. Now when Bill has his final conversation with the three eating establishments, instead of telling each to MAKE Roger’s breakfast, Bill tells them to CANCEL Roger’s Breakfast. After all, I said I wanted all three or none. I would have liked all three, but better no breakfast items than missing breakfast items. He then gives me the bad news: “Sorry Roger, no breakfast this morning”. I may not be happy, but at least I didn’t end up with only fries and a breakfast taco. No problem, I’ll just go down to Kerbey Lane instead. After all, they make awesome gingerbread pancakes and their coffee isn’t half bad either! So let me summarize how the Bill solution worked. I start my breakfast with Bill, who, ironically, doesn’t know anything about food. I tell Bill I want Breakfast. He gives me a ticket that has his phone number and “Roger’s Breakfast” written on it. I take this ticket to each of the eating establishments and hand it in with my order. When the eating establishment takes my order, it calls Bill (remember, his phone number is on the ticket) to let him know it is part of “Roger’s Breakfast” (also on the ticket). The eating establishment doesn’t actually make the order until they hear back from Bill, it just notes what the order is for (one doppio macchiato, one breakfast taco, or one order of fries). When Bill gets the phone call, he adds that eating establishment to his list of those that have rung in as part of “Roger’s Breakfast”. Then I go to Bill and tell him I have finished ordering breakfast. I hand him my ticket. He sees it says “Roger’s Breakfast”. He goes to his list of eating establishments that have rung in as part of “Roger’s Breakfast”. He sees three (Starbucks, El Arroya, and Burger King). Bill now makes two rounds of phone calls. In the first round, he asks each of the eating establishments if they are still willing to make the order. If each says yes, then in the final round, he tells each to go ahead and make the order. If, in the first round, one or more of the eating establishments rejects the order, then in the final round he tells each to cancel the order. He then tells me how things ended up. If he tells me my order was successful, I go pick up my orders. If he tells me my order was canceled, I head for Kerbey Lane. There are seven nice features about Bill’s system. Nice feature number one: Bill doesn’t know anything about food. He has no idea what Starbucks makes, what they charge, or anything else about how Starbucks works. For all he knows, they could be giving away dog food. He only know three things about Starbucks: their phone number (555-2323), with which order they are associated (“Roger’s Breakfast”), and the fact that they seem willing (based on their initial phone call to him) to participate in his system. Nice feature number two: Bill’s protocol could incorporate any business, not just these three eating establishments. If I wanted to include buying my morning newspaper from Sam as part of this morning ritual, I could easily do so. The only requirement is that Sam understands how to work with Bill so that when I hand him Bill’s ticket, he doesn’t look at me like I’m wearing nothing but tie-dye underwear. Nice feature number three: Bill doesn’t need to know in advance what businesses I am going to visit. In fact, even I don’t need to know what businesses I am going to visit. If, while heading to El Arroya, I decide to substitute a Krispy Kreme donut for a breakfast taco, Bill doesn’t care. As long as Krispy Kreme understands Bill’s system, everything will still work fine. Nice feature number four: none of the businesses need to know about each other. Starbucks doesn’t need to know whether I will be having a breakfast taco or a Krispy Kreme donut with my doppio macchiato. All Starbucks knows about is me (the person ordering the doppio macchiato) and Bill (the person coordinating the order). Nice feature number five: Bill’s system is not specific to me. Anybody can use Bill to coordinate breakfast. Janet can use Bill to coordinate her non-fat grande latte and bran muffin. Alice can use Bill to coordinate her tuna melt and coffee. My dog Scoobie can use Bill to coordinate the munching of my couch with the destruction of my slippers. Nice feature number six: Bill’s system isn’t even specific for food. I can use Bill for coordinating any purchases. He is just as happy to coordinate my plane ticket and hotel room purchase as he is my doppio macchiato, breakfast taco, and fries. Nice feature number seven: Bill’s system isn’t even specific for Bill! I can use Barb to coordinate my breakfast just as easily as Bill, as long as Barb uses the same system Bill uses. The only difference between Bill and Barb is that when Barb issues tickets, it will be her phone number printed instead of Bill’s. In order to substitute Barb (or Brenda or Bob or Beth) for Bill, it would be helpful if we had some independent group defining the overall coordination system. If we let Bill define the system, he is likely to come up with some special tweak that will make it difficult to replace him. Unfortunately, I am out of luck. Not only is there no widely accepted standard for breakfast coordinators, there is no Bill. No Bill, no Barb, no Brenda, no Beth. I’m on my own for breakfast. Which is why, as I am writing this, I am drinking a doppio macchiato and eating a bran muffin. A bran muffin, for crying out loud!!! However in the closely related world of software fortresses, things are a little different. Software fortresses, for those of you out of the loop, are self contained island of functionality, much like a Starbucks or a Burger King or an El Arroya. If you aren’t familiar with them, www.objectwatch.com/issue_40.htm will give you an overview. Applications using software fortresses also have to worry about getting their work coordinated, and the techniques for doing so involve using the software equivalent of a Bill. And just like the mythical Bill, the Software Bill is most useful if there is a standard for how he coordinates work with the participating fortresses. Fortunately, in the software world, we do have such a standard. Not only do we have a Software Bill standard, we are blessed with two such standards! After all, if one standard is good, two must be even better! One of these standards is a joint effort by IBM, BEA, and Microsoft. I know, it is hard to imagine IBM, BEA, and Microsoft agreeing on the time of day, let alone a major software standard. But I guess this shows that mutual hatred of a common enemy (doth the Sun also shine?) sometimes makes strange bed fellows. The joint IBM, BEA, Microsoft standard is called WS-T, which stands for Web Service-Transactions. The other standard is an effort of the Business Transactions Technical Committee of OASIS (Organization for the Advancement of Structured Information Standards). The contributors to this standard are Sun, Oracle, BEA, HP, and assorted riff-raff. This standard is known as BTP, which stands for Business Transaction Protocol. Both standards agree on two things. First, they both agree that they are focusing on transactions that span web services (what the cognoscenti would call software fortresses). Second, they both agree on the term transactions to describe the collection of work that must be coordinated across web services, although they do not agree on exactly what a transaction is. Those of you paying close attention may have noticed that BEA was listed as supporting both WS-T and BTP. You may be asking why BEA would be so schizophrenic. Apparently, BEA wanted to hedge their bets so that no matter who finally wins, they can claim to be an early backer. They appear, however, to have thrown more of their weight behind WS-T than BTP, based on the fact that it is WS-T, not BTP, that is listed on their web site under official web service standards. BTP is older than WS-T, but only by two months. BTP came out June 3, 2002. WS-T came out August 2, 2002. The failure of OASIS to get backing from either IBM or Microsoft and apparently only lukewarm backing from BEA must have been somewhat demoralizing, given that these three companies control virtually every business transaction processed in the world today. Then, when these three companies came out with a competing standard just two months later, the impact could only have been devastating to OASIS. These two standards leave you, the enterprise architect, in a rather difficult situation. BTP and WS-T are very different standards that do very similar types of work. Realistically, you can design your web service to be compatible with one or the other, but not both. Which should you choose? Which one is most likely to become the most widely adopted? Will the real web service transaction standard PLEASE stand up! It might seem risky to bet against the combined forces of IBM, Microsoft, AND BEA. Following this logic, you should assume that WS-T will eventually win this shootout. However this might be premature. The main reason I consider it premature to bet on WS-T is simple. WS-T has quite a few problems. You would think that between IBM, Microsoft, and BEA, they could have come up with a decent standard for web service transactions. Apparently, not. There are three main problems with the standard. First, it is overly complicated. Second, it makes completely wrong assumptions about the nature of the work that it is being called upon to coordinate. Third, it includes options that are almost certain to introduce database corruption. Let’s take a brief look at each of these, starting with complexity. The most obvious complexity comes from a misuse of inheritance. WS-T is actually two different standards. There is WS-T, part one, which defines what it calls Atomic Transactions (AT). Then there is WS-T part two, which defines what it calls Business Activity (BA). Both AT and BA are considered to be specializations of (or, in object terms, derivations from) a closely related standard called WS-C, for Web Service Coordination. This inheritance relationship between WS-T and WS-C complicates the WS-T standard. The complexity would be justified if WS-C showed that it was a useful generic framework that could be specialized for purposes other than WS-T. But no such justification is included, other than the fact that WS-C forms the basis for both AT (atomic transactions) and BA (business activity). However, for reasons that I will discuss shortly, AT should never have been included in WS-T in the first place. This leaves only BA type transactions as a “proven” derivation of WS-C. A single derivation is not a justification for adding complexity through inheritance. Next, let’s consider problem two, the assumptions of WS-T. About two thirds of the WS-T specification is dedicated to AT (atomic transactions). The implicit assumption here is that we need an atomic transaction to span web services. Atomic transactions, as defined by WS-T, are the type of transactions that are normally coordinated by a distributed transaction coordinator such as Microsoft’s DTC using algorithms similar but not identical to those used by Bill. These are the true, honest to goodness all or nothing transactions that we usually think of when we think of transactions. However, as anybody who is familiar with the software fortress model would know, one would never, never, never allow true atomic transactions to move from one web service to another. To do so is to violate the trust chasm that naturally separates web services. ATs thus have absolutely no place in a web service transaction specification. Problem three with the WS-T specification is that it includes features that are likely to cause database corruption. I am referring to the so-called phase-0 protocol, part of the AT specification. This is a protocol designed to notify servers (fortresses) that they need to flush data to the database. This implies that the server is caching data. The most likely reason for doing so is that it is built using a Java architecture known as entity beans, of which both BEA and IBM have been active proponents. Entity beans have been widely discredited and should not be used. Entity beans, like all attempts to outsmart the database (as any caching scheme ultimately is) should be approached with considerable trepidation. It is very difficult to design caching schemes that work correctly and that can be coordinated properly with the underlying native database locking mechanisms. Even if you do manage to pull it off, the payoff for getting it right is very small and the penalty for getting is wrong is very large. The risk/benefit is simply not worth it. The one ray of hope for WS-T is that most of the problems are within the two thirds of the specification that deals with ATs. This section could be removed in its entirety without impacting the one third of the specification that has merit, namely the BA section. Even the BA section is not perfect. It has an odd compensation model, for example. Compensation is the action a server must take when it finds itself trapped in a failed BA. In my breakfast example, once Starbucks decides it can’t make my coffee, El Arroya will need to compensate by returning my breakfast taco to the bucket. Given all of my criticisms of WS-T, you might think that I favor the BTP standard. To some extent, this is true. BTP starts, for example, with a better understanding of the underlying problem that needs to be solved. BTP assumes that the transactions one wants to coordinate across web services are very different in nature than the all or nothing transactions that are the focus of WS-T's ATs. This, in itself, is a major improvement. BTP assumes, correctly, that the coordination needed between different web services (or what I would call software fortresses) is more of a contract coordination than a tightly coupled transaction coordination. And yet, even BTP has problems. Its biggest problem is, like WS-T, complexity. While it does not suffer from a confusing and useless inheritance model, it does include two different models for doing essentially the same thing with no reasonable explanation of why both are needed or even how one would choose between the two. BTP has both an "atomic transaction" model and a "cohesive transaction" model. The BTP atomic transaction model only sounds like the WS-T’s atomic transactions (ATs). In fact, they are entirely different. BTP atomic transactions are just groupings of work that will either all complete or all fail/compensate. In this regard, they are much like WS-T's business activities (BA). My breakfast is a good example of a BTP atomic transaction. The BTP cohesive transaction model (a very poorly named model) is more confusing, but it essentially allows individual units of work (such as my doppio macchiato order, at Starbucks) to have greater degrees of freedom. With this model, I could, for example, buy my breakfast taco at El Arroyo, and then change my mind, head over to Krispy Kreme for a donut, and then chuck the whole thing for a bran muffin at Starbucks, all within the same “transaction”. It seems clear to me that any system could be developed with either the atomic or the cohesive model. So why didn't the specification choose one or the other? Probably because the authors could not agree among themselves on which was better. In order to come up with something on which they could all agree, they took the easiest route. They stuck us with both. So there we are. We have two different standards for coordinating work (and several sub-standards within each). What is a poor Software Bill to do? I can tell you what SHOULD happen. IBM, Microsoft, and BEA SHOULD redo their model and make three changes: eliminate the WS-C specification, remove the WS-T dependency on WS-C, and put atomic web service transactions (ATs) where they belong, in the trash. This would gut their proposal, but the remnants would be much stronger. The OASIS group, in turn, SHOULD decide on one single model for coordinating transactions, probably the simplest of the two, the one they call the atomic model. At that point, the WS-T and BTP specifications would be fairly similar, and reasonable people could straighten out the remaining differences. Once they have reached an agreement, they should immediately commit to it. They do know how to commit, don’t they? They are, after all, supposedly transaction specialists! This is what should happen. What will happen? Who knows. We have some powerful egos involved. We have competitors working "together" that are naturally distrustful. Until this is sorted out, Software Bill will just have to wait. As for me, I’m not taking any chances. I’m going to Kirby Lane and ordering coffee and gingerbread pancakes. I don’t need no stinkin’ Software Bill for that. - Roger Sessions GLOSSARY AT - Atomic Transaction, A WS-T term meaning a group of work that exhibits the type of transactional guarantees associated with a distributed transaction coordinator. BA - Business Activity, a WS-T term for loosely coupled transaction. BTP – Business Transaction Protocol, the OASIS standard for cross web service work transactional coordination. DTC - Distributed Transaction Coordinator - a piece of software that guarantees updates to multiple transactional resources, such as databases, are either all done or all not done. CPR – Cardio Pulmonary Resuscitation, what I need after staring at too many specifications before my morning doppio. OASIS - Organization for the Advancement of Structured Information Standards. WS-C - Web Services Coordination Standard, jointly submitted by BEA, IBM, and Microsoft. WS-T – Web Services Transaction Standard, the BEA, IBM, and Microsoft standard for cross web service work transactional coordination. REFERENCES You can find the complete BEA/IBM/Microsoft proposal at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/wstxspecindex.asp This proposal is also posted at IBM and BEA’s web sites. You can find the complete OASIS BTP proposal at http://www.oasis-open.org/committees/business-transactions/ Be sure to read both the primer (which is quite helpful in getting the overall concepts) and the specification itself. SOFTWARE FORTRESS ARCHITECTURE CLASSESChicago, October 15-16The last public class for 2002!Don’t miss this two day master architects' workshop with Roger Sessions on building mission critical systems with the Software Fortress approach. Objects, components, CORBA, J2EE, UML, and N-tier have all failed to address the complex issues of large enterprises. We need a new architectural model for enterprise level software systems. Now we have one: the software fortress model. This class is an overview of the software fortress model, a new approach to building, organizing, and connecting large enterprise software systems emphasizing security, interoperability, reliability, and scalability. Are you trying to get independently developed software systems to work together? Do you need to use both J2EE and Microsoft's .net? Do you hope to use web services to securely collaborate with outside organizations? Are you trying to understand how J2EE compares to Microsoft's .net for building large, enterprise systems? If these are the issues that you struggle with on a daily basis, this class is for you! For more information on this class, see http://www.objectwatch.com/ClassSoftwareFortressA.htm Because of Roger Sessions's heavy speaking and writing schedule, this is the last public class scheduled this year. We do have slots available for private, in-house classes. For information on private, in-house classes, or to register for the public classes, write janet@objectwatch.com. Letters from ReadersDue to the length of the main article, we don’t have space for reader letters. We will catch up in the next issue. ABOUT OBJECTWATCHABOUT OBJECTWATCHObjectWatch specializes in teaching how to architect effective large scale applications. Roger Sessions is the CEO of ObjectWatch and the designer of all of the ObjectWatch workshops. 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 an 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 Legal NoticesThe ObjectWatch Newsletter does not accept outside advertising or rent out its subscription list. This newsletter is Copyright (c) 2002 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. Software Fortresses, Software Fortress Architectures, and the Software Fortress Model are trademarks (tm) of ObjectWatch, Inc., Austin Texas. All other trademarks are owned by their respective companies.
|