What is a servicebus and when do I need one?

You can think of a service bus as the Ethernet of SOA.

First and foremost, it introduces a language of identifying things, like an IP address in Ethernet. This name isn't something inherently physical.

Next, you have something physical involved on each node, like a queue in the case of a bus for supporting semi-connected communication, or an Ethernet card in the metaphor.

Beyond just the physical, there is the "protocol" part of the communication, like the OSI stack for Ethernet. With the bus, this is the client libraries used by application code.

Ultimately, you can view a service bus as providing the next higher level of abstraction for building distributed systems. You can use it also for client-server communication to give you durable one-way messaging as well as for the server to push notifications back to the client.

Specifically, you'll find NServiceBus to be quite lightweight and easy to use once you make peace with its use of queuing technology - your choice of RabbitMQ, MSMQ, Regular SQL Tables, Amazon SQS, Azure Storage Queues, and Azure Service Bus.

Check out the Wikipedia article for Enterprise Service Bus.

A Service Bus acts as yet another layer of abstraction in the never ending quest to implement a good Service Oriented Architecture. The Service Bus can handle some of the heavy lifting seen behind a good Service Oriented Architecture like Messaging, Routing, and Service Co-Ordination.

If you're not sure why you'd want anything like that, I'd suggest reading up on what makes a good Service Oriented Architecture. The book that really opened my eyes and proved the different between just having Web Services and having a true Service Oriented Architecture was Thomas Erl's Service-Oriented Architecture: Concepts, Technology, and Design

This term was introduced with SOA which is in a way the successor (as buzz word) of EAI.

When you need it? That's a good question. It comes with a lot of complexity.

A rule of thumb could by if it solves more problems than it causes.

To be serious if you have a heterogeneous environment and want align (different) applications (using different technology) with business processes. Then it could be helpful to use BPEL (but this introduces problems by migration) for orchestration and choreography

EDIT: What's not on wikipedia, is practice: An ESB can i.g. adapt using special connectors, old terminal applications for use with Corba or Java Enterprise thats meant by interoperability. The drawback is the over 100 'Standards' around SOAP wich don't cooperate without enormous effort.

You definitely need it if you have to interconnect IT systems within six month after a merger of 2 big assurance companies.