1. Trang chủ
  2. » Khoa Học Tự Nhiên

Distributed net programming in c sharp

667 117 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 667
Dung lượng 5,24 MB

Nội dung

Distributed NET Programming in C# ISBN:1590590392 by Tom Barnaby Apress © 2002 (494 pages) This text describes how to use these new NET technologies to build fast, scalable, and robust distributed applications, and answers the many questions about the NET Remoting Framework Table of Contents Distributed NET Programming in C# Foreword About the Technical Reviewer Introduction and AFAQ (Anticipated Frequently Asked Questions) The Evolution of Chapter 1 Distributed Programming Chapter 2 - This is NET Introduction to NET Chapter 3 Remoting Distributed Programming Chapter 4 with NET Remoting Additional Remoting Chapter 5 Techniques Chapter 6 - Understanding XML Web Services Understanding COM Chapter 7 Interop Leveraging Component Chapter 8 Services Chapter 9 - NET Message Queuing Data Access with Appendix A ADO.NET Index List of Figures List of Tables Back Cover Presents information using a style that has been tested while teaching professional developers Covers distributed programming with NET remoting and Web services Written by an experienced trainer at Intertech, Inc., a leader in hands-on workshops for enterprise Web developers With the release of NET, Microsoft has once again altered the distributed programming landscape Almost everything has changed, from data access to remote object calls to the deployment of software components And, of course, NET introduces a new technology in XML Web services that may revolutionize Web development Distributed NET Programming in C# describes how to use these new NET technologies to build fast, scalable, and robust distributed applications Along the way, it answers common questions, such as, How do I use the NET Remoting Framework? What role does COM+ play in the NET universe? How can I interoperate with COM components? What’s the difference between NET Remoting and Web services? How will these changes affect the architecture and design of a distributed application? Tom Barnaby assumes the reader is already familiar with the fundamentals of NET However, a NET overview is provided to concisely explain several of the core NET technologies that are essential for disturbed programming, including building, versioning, and deploying assemblies; garbage collection; serialization; and attribute-based programming About the Author Tom Barnaby is an instructor and a software architect at Intertech, Inc As an instructor, he is in constant contact with frontline developers from around the world As a software architect, he advises companies on the design and implementation of their IT systems Tom has developed a variety of applications ranging from a proprietary 4GL/database system to a fully distributed ERP application Distributed NET Programming in C# TOM BARNABY Copyright © 2002 by Tom Barnaby All rights reserved No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher ISBN (pbk): 1-59059-039-2 Printed and bound in the United States of America 12345678910 Trademarked names may appear in this book Rather than use a trademark symbol with every occurrence of a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark Technical Reviewer: Gordon Wilmot Editorial Directors: Dan Appleman, Peter Blackburn, Gary Cornell, Jason Gilmore, Karen Watterson, John Zukowski Managing Editor: Grace Wong Project Manager: Alexa Stuart Copy Editor: Ami Knox Production Editor: Kari Brooks Compositor: Susan Glinert Stevens Artist: Cara Brunk, Blue Mud Productions Indexer: Valerie Robbins Cover Designer: Kurt Krames Manufacturing Manager: Tom Debolski Marketing Manager: Stephanie Rodriguez Distributed to the book trade in the United States by Springer-Verlag New York, Inc., 175 Fifth Avenue, New York, NY, 10010 and outside the United States by Springer-Verlag GmbH & Co KG, Tiergartenstr 17, 69112 Heidelberg, Germany In the United States, phone 1-800-SPRINGER, email , or visit http://www.springerny.com Outside the United States, fax +49 6221 345229, email , or visit http://www.springer.de For information on translations, please contact Apress directly at 2560 9th Street, Suite 219, Berkeley, CA 94710 Phone 510-549-5930, fax: 510-549-5939, email , or visit http://www.apress.com The information in this book is distributed on an "as is" basis, without warranty Although every precaution has been taken in the preparation of this work, neither the author nor Apress shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in this work The source code for this book is available to readers at http://www.apress.com in the Downloads section To my Mom and Dad, who had no idea what they were starting when they bought me a TI-99/4A computer almost 20 years ago Or did they? About the Author Tom Barnaby is an instructor and software architect at Intertech, Inc., a company dedicated to teaching top programmers how to develop enterprise-level software As an instructor, he is in constant contact with developers from around the world and knows the problems they must solve and the questions they have As a software architect, he advises companies on the design and implementation of their IT systems Before becoming a teacher, Tom developed a variety of applications ranging from a proprietary 4GL/Database system on Unix to a fully distributed ERP application on Windows In his spare time, Tom enjoys playing with his son Max, watching movies, and playing power chords on his electric guitar with the amp volume turned to 11 Acknowledgments Writing a book is by far the hardest thing I have ever done Yet it would have been completely impossible if I didn't have the help and support of the following folks: Thanks to everyone at Apress Gary Cornell, for taking a chance on me, a complete unknown wishing to write about a hot topic Ami "Damn Yer Good" Knox, for being even more analytical than I in regards to writing Grace Wong and Kari Brooks for keeping the great wheels of book production churning even if I was burning (out) And a huge thanks to Alexa Stuart, who somehow kept this project running smoothly in spite of me Finally thanks to Peter Blackburn Thanks to my technical editor, Gordon Wilmot, who not only provided great feedback, but also a tremendous amount of encouragement Thanks to Kelly Kari for proofreading several chapters But more importantly, thanks for actually laughing at my attempts at humor scattered throughout Thanks to everyone at Intertech I feel privileged to work for a company filled with such talented and dedicated individuals Thanks to all my cohorts, Steve Close (Java is toast), Gina Accawi (XML is just a big string), and Andrew "Gunnar" Sondgeroth (see Steve Close) for providing a challenging, fun, and invigorating work environment Special thanks to Andrew Troelsen for contributing an appendix, and whose, um, unique brand of encouragement ultimately lead to this book Finally, thanks to Tom Salonek, founder of Intertech, for somehow tolerating the bizarre antics of us admitted prima donnas Thanks to Rabi, my cat, for keeping my shoulders warm while I worked Finally, and most important of all, many, many thanks to my wife Tammy and son Max Nobody sacrificed more for the sake of this book I will be forever grateful Foreword COM on a wire, also known as DCOM, was a great boon to the distributed programmer Under the model of DCOM, a client was able to interact with COM objects located literally anywhere, without requiring a change of code base Using the indirection provided by AppIDs, stubs, proxies, and channels, our distributed endeavors involved little more than the use of declarative tools such as dcomcnfg.exe and the Component Services snap-in However, all was not well in the world of DCOM (or COM for that matter) Although the clicking of check boxes made COMbased remoting appear quite simple on the surface, we suffered through numerous registry conflicts, a lifetime of passing interface pointers by reference, and the dreaded prospect of crossing firewalls Just as ADO.NET has nothing to do with classic ADO, the NET Remoting story has nothing to do with classic DCOM The most obvious case in point is the fact that NET assemblies are not registered with the system registry Given this, we have no AppID Without an AppID, we have no RemoteServerName value, which means no reference to oleaut32.dll and thus no more COM-based stub and proxies In short, everything we knew about interacting with types across the wire has changed dramatically Under NET, we are provided with dozens of new remoting constructs Not only do we need to contend with numerous TLAs (three-letter acronyms) such as WKO, CAO, and the like, but we are also required to be content with new spins on existing ideas (for example, the distinction between "real" versus "transparent" proxies) as well as the role of XML configuration files Many programmers who are faced with the task of learning the story of NET distributed programming turn to MSDN Here, they are confronted with numerous code examples, partial white papers, and diagrams that require a 21-inch monitor to view in their entirety This approach is bound to lead to frustration and a disjointed knowledge base What is sorely needed is a practical, approachable, and indepth treatment of how all of these new technologies fit together in the context of an Enterprise application Tom's latest book (the one currently in your grasp) provides such a treatment Here, you will find logical and clear explanations that (surprise, surprise) actually provide insight to the richness of the NET Remoting layer Not only does Tom pound out the gory details of this suite of new TLAs, but he also rounds out your understanding by providing coverage of numerous related Enterprise-centric technologies such as building configured components (a.k.a COM+), NET messaging, Web services, and interoperability with classic COM types For a number of years now, Tom and I have worked together here at Intertech, Inc (http://www.intertech-inc.com) I have witnessed him teach numerous courses on the topics of classic COM and NET (including his Expert Distributed NET class) I have also had the pleasure to work with him on numerous development efforts I can speak from the heart when I say you are in good hands Enjoy! Andrew Troelsen Partner and Trainer, Intertech, Inc Minneapolis, MN Figure 8-15: After recompiling with AutoDispatch, two _CarService interfaces are displayed Figure 8-16: Using custom interfaces results in a cleaner view Figure 8-17: Using interfaces also makes it easier to add methods Figure 8-18: The interaction between COM+ and NET in a libraryactivated application Figure 8-19: The event log shows that the Activate and Deactivate methods are called Figure 8-20: With JIT activation and ASAP deactivation, runs immediately after the method returns Figure 8-21: The event log shows five objects are created when the application begins Figure 8-22: Object pooling with JIT activation and ASAP deactivation Figure 8-23: Administrators can set the construction string using Component Services tool Figure 8-24: The coordinating DTC controls the distributed transaction Figure 8-25: The DTC statistics view Figure 8-26: The COM+ context maintains the happy and done bits for the object Figure 8-27: Root objects and worker objects participate within a transaction Figure 8-28: The Application Export Wizard creates a client installation Figure 8-29: COM+ exposes object to clients using DCOM Figure 8-30: Configuring application pooling and recycling Figure 8-31: Specifing SOAP access in the Component Services tool Chapter 9: NET Message Queuing Figure 9-1: The message queuing architecture consists of senders, queues, and receivers Figure 9-2: Installing and configuring MSMQ Figure 9-3: Creating a private queue using the Computer Management tool Figure 9-4: Viewing a message's body in the Computer Management tool Figure 9-5: Queues can also be managed using Visual Studio NET's Server Explorer Figure 9-6: Using Computer Manager to confirm the message was sent to the queue Figure 9-7: The XmlMessageFormatter raises this exception if it does not recognize the message body format Figure 9-8: The queued component architecture provides several components to abstract the details of MSMQ Figure 9-9: COM+ generates queues when you add a queued component Appendix A: Data Access with ADO.NET Figure 13-1: Clients interacting with managed providers Figure 13-2: The System.Data.dll assembly Figure 13-3: Select properties of the DataColumn Figure 13-4: An autoincremented column Figure 13-5: Changes in row states Figure 13-6: Using the ItemArray property Figure 13-7: Collections of the DataTable Figure 13-8: The Inventory DataTable Figure 13-9: Binding the DataTable to a DataGrid Figure 13-10: Removing rows from a DataTable Figure 13-11: Specifying a filter Figure 13-12: Filtered data Figure 13-13: Specifying a range of data Figure 13-14: Ordered data Figure 13-15: Editing rows in a DataGrid Figure 13-16: The Inventory DataTable Figure 13-17: Creating multiple views for the Inventory table Figure 13-18: Collections of the DataSet Figure 13-19: The In-Memory Automobile database Figure 13-20: Navigating data relations Figure 13-21: Navigating parent/child relations Figure 13-22: The DataSet as XML Figure 13-23: The final in-memory DataSet application Figure 13-24: The SQL Server Cars database Figure 13-25: The OleDbDataReader in action Figure 13-26: Triggering the stored procedure Figure 13-27: The OleDbDataAdapter in action Figure 13-28: The InsertCommand Property in action Figure 13-29: Updating existing rows Figure 13-30: Extending the DataSet with new DataRows Figure 13-31: A multitable DataSet on display List of Tables Chapter 1: The Evolution of Distributed Programming Table 1-1: Comparing COM Technologies to NET Technologies Chapter 2: This is NET Table 2-1: Assembly Request Details Chapter 3: Introduction to NET Remoting Table 3-1: Summary of Marshaling and Agility Options Chapter 5: Additional Remoting Techniques Table 5-1: Customer Project Descriptions Table 5-2: Customer Project Descriptions Chapter 6: Understanding XML Web Services Table 6-1: The Body and Parameter Formatting Combinations Table 6-2: Examining the Web Service Project Files Table 6-3: NET Remoting vs Web Services Chapter 8: Leveraging Component Services Table 8-1: Summary of Dispose Behavior in Serviced Objects Chapter 9: NET Message Queuing Table 9-1: Message Queuing Subcomponents Table 9-2: Common Subcomponents Appendix A: Data Access with ADO.NET Table 13-1: ADO.NET Namespaces Table 13-2: Types of the System.Data Namespace Table 13-3: Properties of the DataColumn Table 13-4: Values of the MappingType enumeration Table 13-5: Members of the DataRow Table 13-6: Values of the DataRowState Enumeration Table 13-7: Properties of the DataTable Table 13-8: Members of the DataView Type Table 13-9: Properties of the Mighty DataSet Table 13-10: Methods of the Mighty DataSet Table 13-11: Properties of the DataRelation Type Table 13-12: Types of the System.Data.OleDb Namespace Table 13-13: Core OLE DB providers Table 13-14: Members of the OleDbConnection Type Table 13-15: Members of the OleDbCommand Type Table 13-16: Values of the CommandType Enumeration Table 13-17: Members of the OleDbParameter Type Table 13-18: Core Members of the OleDbDataAdapter Table 13-19: Core Types of the System.Data.SqlClient Namespace Table 13-20: Types of the System.Data.SqlTypes Namespace ... interface, or, in more highbrowed terminology, a fine-grained interface In contrast, objects that are accessed even occasionally by out-of-process code should be designed with chunky interfaces, or course-grained interfaces Here is a chunky version of the Customer class... only to objects exposed to code executing in another process or on another machine Principle 5: Program to an Interface, Not an Implementation Since the previous two principles directly contradict typical objectoriented practices, it may seem as though object-oriented programming. .. Partner and Trainer, Intertech, Inc Minneapolis, MN About the Technical Reviewer Gordon Wilmot is a director of ICEnetware Ltd., a company specializing in Internet and network management and monitoring software

Ngày đăng: 25/03/2019, 16:45

w