|
ObjectWatch Newsletter # 36
|
CONTENTS
One of the results of Roger's recent speaking engagements has been a large number of new readers of the ObjectWatch Newsletter. We would like to specially welcome our new readers from Canada, India, Korea, and Hong Kong. We hope you enjoy reading the newsletter. QUOTATION OF THE MONTH: CONNIVING STATEFUL SESSION BEANS"I'm calling Stateful Session EJBs (SFSBs) the J2EE beasts of burden. I don't care for them. I despise them. I really hate them. I don't dislike what they offer to developers. Rather, I dislike their conniving, misleading, and subtle nature that permits developers to make some of the worst architecture decisions I've seen." - Tyler Jewell, Principal Technology Evangelist for
BEA Systems The winner of the Quotation of the Month Contest is Falk Viczian who gets a choice of a personally autographed copy of Roger Sessions's book, "COM+ and the Battle for the Middle Tier" or the ObjectWatch BBQ apron (also can be personally autographed). Send in your nominations for Quotation of the Month to roger@objectwatch.com and you too can get a personally autographed book or apron! OBJECTWATCH SOFTWARE ARCHITECT MASTER CLASSES COMING TO ZURICHJoin Roger Sessions at either of his two day software architect master classes. If you are interested in comparing J2EE and .NET, join him at J2EE AND .NET: VISIONS, ARCHITECTURES, AND REALITIES. If just .NET is your cup of tea, then join him for the ARCHITECTING FOR .NET. Either of these is guaranteed to change the way you think about Architecting Enterprise systems. For more information on these classes, check out www.objectwatch.com. One sorry note: Because of Roger's heavy speaking schedule, we have no public classes in the United States scheduled until 2002. But we do have a few slots available for private classes. A happy note for our European readers: We are planning one more two day public class this year, J2EE AND .NET: VISIONS, ARCHITECTURES, AND REALITIES, on December 6 and 7th in ZURICH. If you are interested, let Janet (janet@objectwatch.com) know. MAIN ARTICLE: THE SOFTWARE FORTRESS MODEL: A NEXT GENERATION MODEL FOR DESCRIBING ENTERPRISE SOFTWARE ARCHITECTURESBACKGROUNDThree tier architectures are good and bad. They are good in that they are highly scalable, especially as compared to their precursor client/server architectures. They are bad in that the modeling methodologies we use for architecting such systems are out of date. I have been working on a better model for modeling high end enterprise systems. I wanted the model have the following characteristics:
Several existing models have ideas that I felt were particularly valuable.
So I felt any new model had to incorporate the following features:
THE SOFTWARE FORTRESS MODELThe Software Fortress Model incorporates the best features of the N-Tier, Helland, and Silo models, along with my own ideas on interoperability. It also goes beyond any of these to describe the communications channels and trust relationships that are critical to enterprise architectures. This model will evolve, as readers suggest better terminology and further extensions of the model. But I believe the model is mature enough now to deserve an introduction to the real world. The Software Fortress Model assumes that an enterprise architecture is composed of a series of autonomous software fortresses. A FORTRESS is a self-contained software system that has some well defined functionality, such as inventory management. The fortress contains business logic, represented as GRUNTS, and some type of private data repository called a DATA STRONGBOX. A fortress is surrounded by a WALL, the purpose of which is to form an unbreachable separation between the untrusted outside world and the trusted world within the fortress. Communication from the outside world must go through a DRAWBRIDGE. A fortress may have multiple drawbridges, each with specific security constraints and communication protocols. Fortresses can work with other fortresses. An overall enterprise architecture will dictate fortress relationships. Fortresses that are willing to work together are called ALLIES. Allies communicate with each other through one or more drawbridges. The relationships between allies are governed by TREATIES. GUARDS ensure that only trusted allies are using specific drawbridges. Guards enforce the drawbridge security constraints, for example, by authenticating the identity of the ally. Once a guard has accepted a communication request from the outside world it will pass that request on to one or more grunts inside the fortress. Grunts communicate with other grunts only inside their own fortress. Grunts never work with anything outside their own fortress. Grunts do not need to worry about security, because all grunts within a fortress, by definition, trust each other. The data strongbox is secured by the walls of the fortress. It trusts all of the grunts working in its own fortress. When the data strongbox is implemented with a database, security is managed not by the database, but by the fortress walls and the guards implementing the drawbridge protocols. Database security is used only to reinforce the access rights of grunts within the fortress. The key fortress concepts are these:
MAPPING TO EXISTING TECHNOLOGIESThe Software Fortress Model maps well to existing technologies. Walls can be implemented with physical or software firewalls or with operating systems security mechanism, such as Windows integrated security. Grunts can be business components, implemented in either Sun's EJB or Microsoft's COM+, standard business processes, or even legacy systems. Grunts can live together in one process or split up among many processes. They might be deployed using a loosely coupled cluster technology, such as Microsoft's Application Center, to provide ease of management and load balancing. Grunts within a fortress will frequently work together within a single transaction, possibly requiring coordination with some Distributed Transaction Coordinator. Grunt to grunt communication within a fortress can be accomplished using RMI/IIOP, for EJB implemented grunts, or one of the binary .NET protocols, for .NET/COM+ grunts. For grunts implemented as standard processes, grunt to grunt communications can use interprocess communications, RPC, message queues, or shared databases. Data Strongboxes map to existing database technologies such as SQLServer, DB2, or Oracle. Some fortresses may not need a dedicated database and may use instead a well defined and well protected subset of a shared database. Fortresses with low needs for data protection may even use standard files. Fortresses implementing web services might use an internet accessible data strongbox, such as .NET My Services. Drawbridges define the transport and security protocols that allies use to communicate. Most drawbridges are best implemented with asynchronous protocols, such as message queues. One might expect to find either IBM's MQSeries or Microsoft's MSMQ working at this level. Both include various security options that could augment the functionality of the guard. SOAP is also an obvious candidate for a drawbridge, layered either on top of one of the asynchronous message queues or using the more traditional HTTP protocol. Guards can use public/private keys to validate the outsider attempting to cross the drawbridge. They can have programming logic that checks userID/Passwords parameters against validation information stored in the data strongbox. They can also use some third party validation service such as Microsoft's My Passport. Simple treaties might involve an informal understanding between fortresses with some agreed upon drawbridge protocols. More complex treaties, especially those requiring drawbridge translation, might require specialized fortresses that do nothing but manage the treaty relationships. Such a fortress could be implemented using Microsoft's BizTalk technology. TYPES OF FORTRESSESThere are as many types of fortresses are there are businesses. Many, however, fall in one of these five categories:
RELATIONSHIP TO UMLUML is the most popular of the object-oriented design methodologies. It is fully compatible with fortress architectures. While UML can be used for designing at the enterprise design level, its real strength is in designing at the object (i.e. the implementation) level. Grunts will often be implemented with hundreds of objects cooperating together. The ability to document these relationships is critical. UML is a good tool for this. IMPLICATIONS OF FORTRESS ARCHITECTURESThe software fortress is a natural technology boundary and many technology decisions do not need to extend past the fortress walls. For example, one group in a company might need to build for the Unix platform and might therefore choose to use IBM's WebSphere. Another group might need to focus on high scalability and/or low cost units of work. For this group, Microsoft's .NET might be more appropriate. Well designed fortresses should be insulated from each other. One fortress should not care what technologies are used to build another fortress. If the two fortresses wish to work together they will do so through drawbridge technologies. Drawbridge technologies are intentionally independent of the technologies used internally within the fortress. Since the fortress represents a trust boundary, it would be highly unusual for a tightly coupled transaction to span fortresses. True transactions require the holding of database locks. One group would never allow an untrusted entity to determine when and for how long database locks will be held. Since tightly coupled transactions will not span fortresses, there is little reason to use synchronous technologies (such as RMI/IIOP or .NET binary) as drawbridges, although they both work great for communications within the fortress. One of the main reasons we use synchronous communications is to allow the coordination of work within a single tightly coupled transaction. Once we have given up on the idea of coordinating work within a single tightly coupled transaction, we might as well focus on asynchronous communications protocols for the drawbridges. Asynchronous communications protocols have better reliability, scalability, and load balancing characteristics than do synchronous communications protocols. Since we have complete trust within the fortress, we can safely manage our database locks. Therefore we will often use tightly coupled transactions to coordinate the work being done within the fortress. Tightly coupled transactions implies synchronous communication, since, as I just pointed out, asynchronous protocols do not carry transactional context. We often need to coordinate workflow across fortresses. Without the ability to use tightly coupled transactions for this purpose, we have no alternative other than using some form of compensatory transactions. Since we have no real standards for compensatory transactions, the definition and enforcement of compensatory transactions will need to be part of the definition of the treaty relationships. ADVANTAGES OF THE SOFTWARE FORTRESS MODELThe Software Fortress Model allows an enterprise to model its different software systems and to describe how those systems are related to each other. The Software Fortress Model focuses the attention of the enterprise architects on the important enterprise issues of security (guards), interoperability (drawbridges), and cooperation relationships (treaties). The Software Fortress Model can help resolve technology debates within companies, such as whether J2EE or .NET should become the corporate standard. The Software Fortress Model represents an "agreement to disagree". It allows different systems to be built on different technologies and focuses attention instead on the more important issues of interoperability between those systems. The Software Fortress Model gives us a natural way to describe how legacy systems will be viewed within the enterprise. They become one of many software fortresses, with their own walls, guards, and, most likely, data strongboxes. I believe that the Software Fortress Model will be a major help to enterprise architects in getting a handle on the overall complexity of their enterprise systems. SUMMARYThree tier design techniques have not kept up with serious enterprise architectures. The Software Fortress Model maps better to both current technologies and current problems. It works well with both Microsoft's .NET and Sun's J2EE technologies and gives companies a natural way to manage the scope of technology decisions. The Software Fortress Model takes important ideas from classic N-tier architectures, Pat Helland's fiefdom/emissary architecture, traditional notions of data silos, and my own advocacy for a corporate focus on interoperability. INVITATIONThere are still ideas that need more work. I invite readers to send in suggestions, improvements, and to discuss how well this maps to existing enterprise systems. Stay tuned for more information on this area. - Roger Sessions POSTINGS BY VERY IMPORTANT PEOPLE: SUN'S CRAIG RUSSEL RESPONDS TO OBJECTWATCH NEWSLETTER #35It is the policy of the ObjectWatch Newsletter to always offer people or companies we criticize a forum in which to respond. We believe that only through reading all sides of important issues can our readers make truly informed decisions. In the ObjectWatch Newsletter #35, we criticized Sun's design of the Java Data Objects PersistenceManager interface. . We do not like this interface because it bundles run-of-the-mill data access methods with highly dangerous system level methods meant to manage internal database caches and coordinate transactional integrity. We believe that making these system level methods available to naive data access clients is an open invitation to database corruption. It's hard to imagine what Sun was thinking of when they packaged these disparate methods together in a single interface. We have not received any response from Sun. However, we have noticed that Sun's Craig Russell posted a response to this article on TheServerSide.com. Craig Russell is the Java Data Objects Specification Lead at Sun, and is presumably responsible for the design of the Java Data Objects interfaces, including that of the PersistenceManager. In our original article, we noted that Java Data Objects is still only a draft specification. We assumed that Craig, in his response, would say that Sun understands the issue, and that the interface problems would be sorted out before the draft was finalized. Unfortunately, that is not what Craig said. Instead, Craig said, "The whole middle tier architecture of J2EE is apparently lost on Roger Sessions. J2EE is a component architecture, wherein some components live in the middle tier and some components live in the client tier. There is a strong architectural barrier between the client side and server side components." He continues, saying "His 'latte counter' example is too weak to adequately describe the security aspects of a middle tier server. Just as Z would not allow Roger to wander around back to scrounge for water, no reputable server would allow a client to wander around back to access server implementation objects like JDBC Connections, JDO PersistenceManagers, or JCA TransactionManagers." His reply can be read in its entirety at www.theserverside.com/resources/article.jsp?l=RusselvsSessions Needless to say, we are sadly disappointed in Craig's reply. We believe it would be irresponsible of Sun to release the Java Data Objects specification in its current state. Should Sun actually release this specification, we hope it will be ignored by the Java community. Any implementation of this interface we believe will expose customers to the risk of transactional failure, cache inconsistency, and database corruption. At ObjectWatch, we believe that database corruption is a bad thing. We hope that Sun agrees with us on at least this issue. As always, we invite Sun or any other Java vendor that disagrees with our analysis to send us a rebuttal. We will be happy to print responsible replies. ABOUT OBJECTWATCHObjectWatch specializes in teaching how to architect effective enterprise architectures. 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 www.amazon.com/exec/obidos/ASIN/0471317179/objectwatchA Recent issues of this newsletter are available at www.objectwatch.com#35: Living on the Right Side of the Fence (A Look at Java DataObjects) #34: Follow-up on Application Center #33: Is Java Language Neutral? #32: ClusterMuster Big Box Buster Lacks Muster: A look at Application Center, and the marketing thereof. #31: Finding Your Soul Mate: An Introduction to UDDI #30: CIO Alert: ObjectWatch Responds to Gartner; We respond to a recent Gartner report titled "Microsoft COM is No Longer a Strategic Choice". #29: Letter from the PDC: The unveiling of the Microsoft .NET platform. #28: Objects and Components: A comparison of object and component based technologies. #27: Greg Pfister responds to ObjectWatch Newsletter #26 #26: Measuring Scalability: A discussion of the proper way to analyze the scalability of a middle tier system. #25: SOAP: An introduction to this important interoperability technology. #24: The Sun White Papers: A rebuttal to the Sun White papers comparing EJB to COM+. #23: Why I Don't Drive a Lamborghini: A comparison of big-iron systems and clusters of low end systems. #22: The Best Feature of COM+: A Introduction to COM+. Legal NoticesThe ObjectWatch Newsletter does not accept outside advertising or rent out its subscription list. This newsletter is Copyright (c) 2001 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.
|