February 17
If you have any questions in mind please mail them to me at namratha1@gmail.com in the below format.
E.g.
Usergroup : Mumbaisuergroup.
Nick Name : Nasha
Question : Explain ur Q in brief
What is a diff between an abstract class and an interface ? What would govern your decision for its usage in .NET?
-- A an abstract class is a class which cannot be instantiated and an interface is a set of functions. Thier usage would goverened by the follwoing reasons :-
a. If I have some common functions to be implemeted in the base class then one should use abstract class as Interface cannot have funcation implementations.
b. Languages like C# and VB.NET only allow single inheritance of classes hence you have only one base class and rest will have to be created as interfaces.
e.g. If I did my class A to inherit from Class B and Class C .. then inheritance can only be done from one of these classes the one will have to created as an interface.
What are the different types of polymorphism ?
-- There are two types of polymorphism inheritance based and interface based. In Inheritance based you have a common base class and in interface based you have a common interface between classes.
How can you view the procedure text from Query Analyser ?
-- Use sp_helptext <procedure name>
Can you have two applications on the same machine one which is using .NET Framework 1.0 and the other using 1.1 ?
-- Yes
You have an application which yoour client is going to view from his end. If you dont want the cleint to view details of the error message then what will you do?
-- Set the custom errors property of to Remoteonly. The other two options are On which will not display the error details on both remote as well as local machine and the other one is Off which is always display the complete error message on both remote as well as local machine.
If you are using a web service and you want its path to be picked up from the config file what will you do ?
-- Set its behaviour property to dynamic this will add a new appSetting entry in the config file for the webservice path.
Can I view Intermediate Language of a .NET assembly?
-- Yes. MS supply a tool called Ildasm, which can be used to view the metadata and IL for an assembly.
What is the maximum number of classes a .NET DLL can contain?
-- Unlimited
Can you call the garbage collector explicitly?
-- System.GC class exposes a Collect method - this forces the garbage collector to collect all unreferenced objects immediately.
Can I serialize Hash table with XmlSerializer?
-- XmlSerializer will refuse to serialize instances of any class that implements IDictionary, e.g. Hash table. Soap Formatter and Binary Formatter do not have this restriction.
What is difference between "tlbexp" and "Regasm" tools?
-- Both these tools are used to create CCW from a .NET Assembly, the only difference being that Tlbexp will not register the type library unlike regasm.
February 09
Configuration files have always been a part of our applications. They generally hold data which is configurable, so instead of hard coding the parameters in the code we can read them form a config file. In .NET Remtoing we have some xml elements to configure our channel and remote objects.
All the elements are placed under the main xml element <configuration>. For .Net Remoting there is a tag named <system.runtime.remoting>. Let us look at the various elements provided for .NET Remoting which will be placed under <system.runtime.remoting> .
a. The first tag to come under <system.runtime.remoting> is <application> application. This tag is used to specify the application name. On the server side for specifying the server name and on the client side its the name of the client application.
E.g. If we have a remote server name "MyRemoteServer" then the server configuration will specify it in the application tag as follows
<application name ="MyRemoteServer" >
|
|
<application/>
b.On the server side we have <service> element. This element is used to specify a collection of remote objects we host. This element can hold <wellknown> and <activated> elements under it , which are used to specify the type of remote object.
<service>
|
|
</service>
c.On the client side instead of service we have a <client> element. <client> has an attribute url to hold the path of the remote server. Like <service> it can have <wellknown> and <activated> sub-elements under it. They are used to specify the type of remote object and hold the url of the remote server.
E.g.
<client url ="tcp://MyMacName:6789/MyRemoteServer>
|
|
</client>
d. <wellknown> is used on the server and client to specify the type of remote object On the server side it is used to specify the mode of the remote object using the mode attribute, type of remote is specified as Namespace.Classname followed by the name of assembly. ObjectURI mentions the server object's URI. Its a subelement under <service>.
On the client side it is used to mention the type again as Namespace.Classname and url holds the complete url of the server object mentioning the protocol, port, application name and the object URI. Its a subelement under <client>
E.g.
Client : - <wellknown type = "MyNamspace,MyRemoteServer" url = "protocol://MyMacName:6789/MyRemoteServer/URI" />
Server :- <wellknown mode = "Singleton" type "MyNameSpace.MyRemoteServer, RemoteServer" objectURI="URI" />
e. The activated element is used for client activated objects [CAO]. It specifies type containing the complete name of the object i.e. Namespace.ServerName along with the name of the assembly. This should be specified for CAO's on both server side and client side.
Its a subelement of <clilent> on client side and <service> on server side.
E.g.
<activated type = "MyNamespace.MyRemoteServer, RemoteServer" />
f. Generally it is observed that the config file are used to configure channels. To specify channel we have the channel element. Under channel we have channeltype. It is used on both the client and server side. The channeltype element holds the type of channel with its assembly name and the port number. Its a subelement under <appplication> generally mentioned below <service> or <client>.
E.g.
<channels>
<channel type = "System.Runtime.Remoting.Channels.Http.HttpChannel,System.Runtime.Remoting" port=6789 />
<channel type = "System.Runtime.Remoting.Channels.Tcp.TcpChannel,System.Runtime.Remoting" port=6789 />
</channels>
February 07
Continuing our discussion with LifeTime Management :-
Lifetime Management has been one of the biggest challenges in distributed applications. It is difficult to detect for client and server that whether the other is available or not.
To check whether the server is available or not, the least that the client can do is to ping the server . But this mechanism is fine if we are on LAN but is not suitable for Internet based applications. If the client is unable to check the presence of the server, the last thing it can do is call a method on the server object. If the server object is not present than an exception will be raised.
.NET Remoting has some up with a solution for lifetime management called as the Leasing Distributed Garbge Collector i.e.LDGC. Lifetime managment becomes very important for client -activated objects as they can have state and need to be aware of resources that they use. So lease becomes very important for these objects when the lease time is reached the lease expires and the object is marked for garbage collection.
All objects inherited from MarshalByRef generally do their own lifetime managment and do not reside in memeory for a long time. Inorder to implement custom lifetime managment we need to override InitializeLifetimeService(). The life time of the object is controlled by setting the lease time , lease manager and Number of sponsors. When we say number of sponsors we mean that if no sponsors are available within the SponsorshipTimeOut then the lease expires and te object is garbage collected. Lease Manager keeps a watch on the object and marks it for garbage collection when the lease expires. All the sponsors who want the object have to first register themselves with the lease manager and than renew the lease time for the remote object periodically.
Inorder to handle lease of an object we need to override InitializeLifetimeService(). When we override this method the call to the base class InitializeLifetimeService() returns ILease object. We need to set properties of this object inorder to renew the object lifetime.
ILease defines the following properties to control lease time of an object :-
Lease Time :- Time until the object will be marked for garbage collection. The default current lease time is 5 minutes .. setting it to 0 will be setting it to infinite
RenewOnCallTime :- Its the lease time set on each method call on the remote object. Default 2 minutes
SponorshipTimeout :- The amount of time by which the lease manager should be able to find a sponsor for the object. If not than the lease expires and the object is marked for deletion. Default 2 mintues
LeaseManagerPollTime :- Its the time interal after which the lease manager checks for object lease expiration. Default is 10 seconds.
There are lot of ways for renewing object lease or liftime.
a. As we saw above the object life time will be automatically renewed if the CurrentLeaseTime is less than the RenewOnCallTime once there is a method call made on that object.
b. One can control the object renewal by calling Renew method. InitializeLifetimeService() which returns us an ILease object exposes a method called ILease:Renew().
c. Object renewal can be left at Sponors discretion. The sponors need to implement ISponsor interface. This mechanism need the sponsor to register by calling the Register() method of the ILease interface. When the lease is about to expire the sponsor will be asked if the lease needs to be renewed. This mechanism is best for Client-activated objects and when you want remote objects to live for a long time.
.NET's approach towards lifetime management is better than other older aproaches like pinging for an object and reference counting.
February 04
Continuing our yesterdays discussion letz start with formatters.
Formatters :- .NET framework provides us with two formatters classes namely SoapFormatter and BinaryFormatter. You can find them under namespace System..Runtime.Serialization.Formatters.Binary and System.Runtime.Serialization.Formatters.Soap . Formatters are used to transfer data to and fro from a channel. They are associated with a channel through formatter sink objects and providers.Both these formatters implement a common interface know as IRemotingFormatter. IRemoting is available under System.Runtime.Remoting.Messaging Namespace. This interface has two methods Serialize and Deserialize which help to serialize data to be transfered across.
Both these formatters are primarily used for serialization and deseralization of method calls and reponses.When a method call is made , the method call information has to be serialized inorder to be sent to the remote object. To execute the request it has to be deserialized. After the request is executed on the remote object the response has to be serialized and sent. The response is further deserialised by the client.
You can also create your custom formatter and associate it to a channel.
Object Activation :- Remote objects can be either client activiated or server activated. You can get reference to the remote objects using the Activator class. Activator.GetObject method returns you a reference to the proxy of a server activated object. Activator.CreateInstance returns you a refernce to a proxy of client Activated object.
Server or WellKnown Objects :- Activator.GetObject and RemotingServices.Connect both return a reference to a proxy of a server or wellknown object. There are two types of the wellknown service type. SingleCall and Singleton.
SingleCall :- SingleCall objects dont hold any state that means for every call you make to the remote object a new object is created. So there is no object to persist data in between calls. This can be efficient as the server does not need to hold any resources for the client.
Singleton :- As the word singleton says the same object is used across client. This object can be used to share data across clients. As with any other singleton object one has to be careful of locking of resources and concurrency.
When we create a server activated remote object we can register the wellknownservicetype as either of them.
Client-Activated Objects :-Activator.CreateInstance creates a client activated object. Life-time of the client activated object is in the hands of the client unlike the server activated objects i.e. the object lives till the time the cleint wants it to live. On creating a client activated object yuo can specifiy the lease time of the object. Since the the client has reference to the object, object state can be maintained easily.
Proxy :- We just saw above that both the static methods Activator.GetObject and Activator.CreateInstance return us reference to a proxy object. In Remoting there are two types of proxies Transparent and Real Proxy. Transparent proxy is an object that looks like the remote object but all the method calls are further redirected to real proxy. Transparent proxy calls the Invoke method of the real proxy object.
To check whether the proxy received by you is a real proxy or a transparent proxy .NET provides us with a method called IsTransparentProxy exposed by RemotingServices class. This method takes the refrence to the proxy object as a parameter and returns a boolean value.
MessageSinks :- Message sinks are interceptors that can change the messages and perform some additional actions. Whenever we create an object we get a reterence to its proxy. This proxy uses a chain of envoy sinks to pass messages to the channel. All message sinks implement IMessageSink Interface which has one property NextSink and two methods SyncProcessMessage and AsyncProcessMessage.
NextSink returns a refernce to the next sink in the hierarchy to pass the message. SycnProcessMessage method processes a message request in a synchronous manner and returns a response message [ a an IMessage object ]. AsyncProcessMessage method process the message request asynchronously and returns a reference to the passed async message [ an IMessageCtrl object].
There are mainly three types of message sinks i.e. Envoy,Server Context and Object.
Envoy Sink :- They are created from the server context so the server can pass messages to the client. Envoy sinks are generally used to collect client info and pass it to the server.
Server Context Sink :- When a message is received on the server side it is passed to the server context sink.
Object Sink :- An object sink is created for a particular object if its class defines context sinks and attributes.
February 03
Channels :
Channels are used for communication. In .Net Remoting Channels are used to transport messages from client to server to and fro. When a message is sent from client to server, client is the sender and server is the receiver and vice-versa. Since channel is used to transport messages before starting any type of communication with the remote object it is important to setup a channel for communication.
To create a channel one needs to implement IChannel interface ( the primary interface for any channel). The two main operations of channels are to send and receive messages. For any channel to receive messages it needs to implement IChannelReceiver interface and to send messages it needs to implement IChannelSender Interface.
.NET Framework provides us with two in built channels TCP and HTTP. Both TCP and HTTP implement IChannelReceiver and IChannelSender interfaces.
Since all the channels implement IChannel interface let us check it out first. IChannel has two main properties ChannelName and ChannelPriority. ChannelName enables us to give a a reference name to the channel. ChannelPriority enables us set the priority.Channels with higher priority value are given higher priority.
TCP and HTTP channels, each are further classified into Client and Server channels. Client channels implement IChannelSender interface and Server channels implement IChannelReceiver interfaces respectively.
IChannelSender :- This interface is implemented by any channel to send messages. This interface has an important fuction called as CreateMessageSink. This method takes 3 parameters URL,remotechanneldata and objectURI and returns a reference to the newly created message sink. URL is the address to which the messages are to be delivered.Remotechanneldata holds the data about the target channel [ server channel ].ObjectURI is parameter is unintialized. When we call CreateMessageSink either URL or RemoteChannelData can be null but not both.
IChannelReceiver :- This interface is implemented by any channel to receive messages. It has an important property called ChannelData and 3 functions called GetUrlsforUri, StartListening and Stop Listening. ChannelData is a readonly property which returns an object containing channel specific data. GetUrlsforURI will return all the urls of that can be used to locate the remote object. Server channels implement IChannelSender to receive messages from the client. StartListening and StopListening helps the server channels to start or stop listening to its corresponding cleint channel.
Let us look at the the channels which implement the above interfaces:
TCPClientChannel :- Uses binary formatter to serialize messages. This channel is the last in the sink heirarchy who is responsible for finally sending out the message across to the server using TCP Protocol. TcpCleintChannel implements IChannelSender interface.
TCPServerChannel :- This channel works in conjunction with the client channel. Binary formatted messages sent by the client channel are accepted by the server channel. Unlike the Client Channel, the server channel is the first in the message sink heirarchy from the server side to receive messages. TcpServerChannel implements IChannelReceiver interaface.
TCPChannel :- This channel implements both IChannelSender and IChannelReceiver interfaces that enables it to both send and receive messages.
HTTPClientChannel :- Uses SOAP formatter to serialize messages to xml format. Like the TCPClientChannel is last the sink heirarchy and implements IChannelSender interface. This channel uses HTTP protocol to transport xml messages.
HTTPServerChannel :- Like the TcpServerchannel it also works in conjunction with the client channel to receive messages using HTTP protocol and is first in the sink heirarchy on the server side.
HTTPChannel : Implements both IChannelSender and IChannelReceiver that enables it to send and recieve messages using HTTP.
Note :- All HTTP Channels inherit from a common base class called BaseChannelWithProperties which in turn inherits from BaseChannelObjectWithProperties. They aid in reteriving properties of any channel sink in the sink heirarchy.
This is all about channels will continue tomm with sinks and formatters.
January 31
Today we will be discuss .NET Remoting. Let us start of with its Introduction :-
Introduction :
Remoting is used to access objects in the same and another application domains. When the client accesses an object in another app domain the client receives a proxy to the real object. Hence when the client calls any method of the remote object it actually calls a method on the proxy. Proxy is has a similar interface to the real object. The proxy in turn sends a message to the message sink. The message sink further sends the message to the channel. Channel is responsible for connecting the client and the server. Client Side sends data to the server side channel. The server side channel in turn talks with the server side message sinks. There can be one or more message sinks. The last message sink calls method on the remote object. The result is sent using the same approach.
Classes and Remoting:
There are two main types of objects that play a very important role in remoting Marshal by value and Marshal by ref.
Marshal by value:
Objects of type marhsal by value are not bound to any application domain. They can be serialized and passed across through channels. To serialize these objects it is necessary that there class implements ISerializable interface or are marked with the [Serializable] attribute.
Marshal by ref:
Classes of type marshal by ref are derived from a class known as MarshalByRefObject. Any object of type MarshalByRefObject is never passed across application domains. Hence one needs a proxy to access these objects from another application domain. Unlike the classes which are of type Marshal by value which are not bound to there application domain Marshal by ref classes are bound to there application domain. Objects of these classes are also called ContextBound objects as they are only valid in the creation context.
Classes that cannot be serialized and not derived from MarshalByRefObject are non-remotable objects
Context:
We all know that a single application process can have multiple application domains. An application can have multiple contexts. A Context groups object as per there execution requirement. Hence Marshal by ref objects are context bound in there application domain coz thereexecution requirement is defined in there application domain. Thus a proxy is used to make a call to these objects so that call is executed in the same app domain or context.
Creating an application domain creates a default context for that application domain.An context also defines certain context properties which is required by objects created in it.
Tools 
