Distributed Application Design: ASP.NET Web Services vs. .NET Remoting
ASP.NET Web services favor the XML Schema type system, and provide a simple programming model with broad cross-platform reach. .NET Remoting favors the runtime type system, and provides a more complex programming model with much more limited reach. This essential difference is the primary factor in determining which technology to use. However, there are a wide range of other design factors, including transport protocols, host processes, security, performance, state management, and support for transactions to consider as well.
Security
Since ASP.NET Web services rely on HTTP, they integrate with the standard Internet security infrastructure. ASP.NET leverages the security features available with IIS to provide strong support for standard HTTP authentication schemes including Basic, Digest, digital certificates, and even Microsoft® .NET Passport. (You can also use Windows Integrated authentication, but only for clients in a trusted domain.) One advantage of using the available HTTP authentication schemes is that no code change is required in a Web service; IIS performs authentication before the ASP.NET Web services are called. ASP.NET also provides support for .NET Passport-based authentication and other custom authentication schemes. ASP.NET supports access control based on target URLs, and by integrating with the .NET code access security (CAS) infrastructure. SSL can be used to ensure private communication over the wire.
Although these standard transport-level techniques to secure Web services are quite effective, they only go so far. In complex scenarios involving multiple Web services in different trust domains, you have to build custom ad hoc solutions. Microsoft and others are working on a set of security specifications that build on the extensibility of SOAP messages to offer message-level security capabilities. One of these is the XML Web Services Security Language (WS-Security), which defines a framework for message-level credential transfer, message integrity, and message confidentiality.
As noted in the previous section, the .NET Remoting plumbing does not secure cross-process invocations in the general case. A .NET Remoting endpoint hosted in IIS with ASP.NET can leverage all the same security features available to ASP.NET Web services, including support for secure communication over the wire using SSL. If you are using the TCP channel or the HTTP channel hosted in processes other than aspnet_wp.exe, you have to implement authentication, authorization and privacy mechanisms yourself.
One additional security concern is the ability to execute code from a semi-trusted environment without having to change the default security policy. ASP.NET Web Services client proxies work in these environments, but .NET Remoting proxies do not. In order to use a .NET Remoting proxy from a semi-trusted environment, you need a special serialization permission that is not given to code loaded from your intranet or the Internet by default. If you want to use a .NET Remoting client from within a semi-trusted environment, you have to alter the default security policy for code loaded from those zones. In situations where you are connecting to systems from clients running in a sandbox—like a downloaded Windows Forms application, for instance—ASP.NET Web Services are a simpler choice because security policy changes are not required.
Conceptually, what is the difference between early-binding and late-binding?
Early binding – Binding at Compile Time
Late Binding – Binding at Run Time
Early binding implies that the class of the called object is known at compile-time; late-binding implies that the class is not known until run-time, such as a call through an interface or via Reflection.
Early binding is the preferred method. It is the best performer because your application binds directly to the address of the function being called and there is no extra overhead in doing a run-time lookup. In terms of overall execution speed, it is at least twice as fast as late binding.
Early binding also provides type safety. When you have a reference set to the component’s type library, Visual Basic provides IntelliSense support to help you code each function correctly. Visual Basic also warns you if the data type of a parameter or return value is incorrect, saving a lot of time when writing and debugging code.
Late binding is still useful in situations where the exact interface of an object is not known at design-time. If your application seeks to talk with multiple unknown servers or needs to invoke functions by name (using the Visual Basic 6.0 CallByName function for example) then you need to use late binding. Late binding is also useful to work around compatibility problems between multiple versions of a component that has improperly modified or adapted its interface between versions.
What is an Asssembly Qualified Name? Is it a filename? How is it different?
An assembly qualified name isn’t the filename of the assembly; it’s the internal name of the assembly combined with the assembly version, culture, and public key, thus making it unique.
e.g. (“”System.Xml.XmlDocument, System.Xml, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″”)
How is a strongly-named assembly different from one that isn’t strongly-named?
Strong names are used to enable the stricter naming requirements associated with shared assemblies. These strong names are created by a .NET utility – sn.exe
Strong names have three goals:
· Name uniqueness. Shared assemblies must have names that are globally unique.
· Prevent name spoofing. Developers don’t want someone else releasing a subsequent version of one of your assemblies and falsely claim it came from you, either by accident or intentionally.
· Provide identity on reference. When resolving a reference to an assembly, strong names are used to guarantee the assembly that is loaded came from the expected publisher.
Strong names are implemented using standard public key cryptography. In general, the process works as follows: The author of an assembly generates a key pair (or uses an existing one), signs the file containing the manifest with the private key, and makes the public key available to callers. When references are made to the assembly, the caller records the public key corresponding to the private key used to generate the strong name.
Weak named assemblies are not suitable to be added in GAC and shared. It is essential for an assembly to be strong named.Strong naming prevents tampering and enables assemblies to be placed in the GAC alongside other assemblies of the same name.
How does the generational garbage collector in the .NET CLR manage object lifetime? What is non-deterministic finalization?
The hugely simplistic version is that every time it garbage-collects, it starts by assuming everything to be garbage, then goes through and builds a list of everything reachable. Those become not-garbage, everything else doesn’t, and gets thrown away. What makes it generational is that every time an object goes through this process and survives, it is noted as being a member of an older generation (up to 2, right now). When the garbage-collector is trying to free memory, it starts with the lowest generation (0) and only works up to higher ones if it can’t free up enough space, on the grounds that shorter-lived objects are more likely to have been freed than longer-lived ones.
Non-deterministic finalization implies that the destructor (if any) of an object will not necessarily be run (nor its memory cleaned up, but that’s a relatively minor issue) immediately upon its going out of scope. Instead, it will wait until first the garbage collector gets around to finding it, and then the finalisation queue empties down to it; and if the process ends before this happens, it may not be finalised at all. (Although the operating system will usually clean up any process-external resources left open – note the usually there, especially as the exceptions tend to hurt a lot.)
Please read all the post in the Dotnet Framework series.
Reference : Dilip Kumar Jena ( https://mstechexplore.wordpress.com )
Exploring Dot Net with Dilip Kumar Jena 