Actually, I'm not familiar to how identity-based and certificate-based systems work, so ,can anyone give me a detail and comprehensive answer to this question? Moreover, in what environments the identity-based systems is recommended(or needed) and why?
Public key crypto vs. identity-based crypto made short:
In traditional public key cryptography, a user $A$ generates a private/public key pair $(sk_A,pk_A)$ and since this key pair has absolutely no indication to which indentity (user $A$) it belongs, it is necessary to certify the public key, i.e., bind the public key $pk_A$ to the user $A$'s identity. This is commonly done by lettig some trusted authority sign $pk_A$ with additional identifying information of user $A$ after user $A$ proves by some means that he really is user $A$ (the result is what is called a certificate).
Identity-based cryptography aims at letting the users public key be its identity (e.g., the email address) and so to remove the requirement for certificates. In ID based cryptography a user $A$ uses his identity (e.g., his email address) as public key. Now, however, since this information could be used by anybody as an identity it is clear, that there needs to be some other entity involved in generating the respective private key. We require a trusted authority (the key generation center) to compute the private key $sk_A$ that corresponds to the public identity string $ID_A$ and this trusted authority has to check whether $ID_A$ (e.g., the email address) indeed corresponds to $A$ and then issues the private key $sk_A$ corresponding to the identity $ID_A$. Since the private keys are generated with respect to some public parameters, every party in the system needs to be in possession of an authentic copy of the public parameters (this is similar to a root CA certificate in certificate-based crypto).
Pros and Cons
In theory, the main advantage of identity-based crypto and in particular identity-based encryption is that you do not need to obtain the public key of the recipient but simply can use the recipients identity (=public key) for encryption and the recipient actually does not even need to be in the possession of the respective private key at the point of time when the ciphertext is produced.
In practice, this, however may be not that easy to achieve as theory makes it look like.
Actually, there are various issues which are discussed in the papers I have linked in my previous comments, but I think the most relevant issues are:
I would say that, since distributed key generation has not really shown to be used in practice, identity-based crypto is more for closed environments (enterprises, maybe sensor networks) and not for open environments. Essentially, in any situation where key escrow is not such an issue, key renewal can be efficiently performed and revocation checks can be made efficient, identity based crypto may be an alternative.
Anyways, it seems that a hybrid between identity-based crypto and certificate-based crypto seems more realistic.
There is also something in between:
Certificateless public key cryptography is inbetween these two approaches. It aims to get rid of the problem that the key generation center gets to know the entire private keys of all users. In this approach the key generation center only computes a partial private key of user $A$ based on the identity $ID_A$ and the user then combines this partial private key with some secret information (only known to him). Then the user needs to take the public parameters of the key generation center and combines the secret with this parameter to obtain the user's public key. The advantage here is, that this public key does no longer need to be certified, since it contains the identity $ID_A$ of user $A$ and if the key generation center is trusted (and the public parameters of the key generation center are authentic) one can assume that the user associated to $ID_A$ really corresponds to $A$ and holds the corresponding private key.