Bøker av Tom Barnaby

COM ON A WIRE, also known as DCOM, was a great boon to the distributed pro- grammer. Under the model ofDCOM, a client was able to interact with COM objects located literally anywhere, without requiring a change of code base. Using the indi- rection 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 COM-based 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.

Expert ASP.NET 2.0 Advanced Application Design will help you derive maximum performance and reliability from the distributed applications you create with ASP.NET 2.0.The book first looks at some of the non-functional requirements that impact the design of a distributed application. It then relates them to the servers and services available in the .NET 2.0 Framework. ASP.NET 2.0 is the central process for use in distributed .NET applications, and the book closely examines the ASP.NET 2.0 Framework and its hosting environment, Internet Information Server (IIS). The book looks at how ASP.NET 2.0 is used by different packages within .NET (like Web Services), and explores how it can be extended to meet your own custom requirements.The second part of the book drills down and examines some of the common architectural challenges encountered when developing application designs. The book walks through the tiers of the .NET Framework, starting at the client level and exploring the internals of the page type, enhancements to ViewState, client script generation, and new out-of-band callbacks. At the middle tier, the book examines Web Services, Remoting, COM+, MSMQ, and mix and match communication options to suit your own requirements. This section wraps up by previewing Windows Communication Foundation, which aims to unify these technologies.The third part of the book examines the data layer of your distributed applications. This includes enhancements to the Managed Providers in 2.0, the new transactional model, and a preview of usage guidelines for SQL Server 2005. By the books conclusion, you will be able to select with confidence the most appropriate design elements for your purposes, elegantly connecting them, and ensuring you get the very best from the ASP.NET 2.0 Framework.

COM ON A WIRE, also known as DCOM, was a great boon to the distributed pro- grammer. Under the model ofDCOM, a client was able to interact with COM objects located literally anywhere, without requiring a change of code base. Using the indi- rection 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 ofDCOM (or COM for that matter). Although the clicking of check boxes made COM-based 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.