Highly Scalable IM Server (AIM/MSN/YIM)

We currently run a service similar to Meebo.com. The general architecture is that we have a frontend (client) that communicates with our backend (server). The client will ask the server to sign a specific account online. In turn, the server will link the client with that IM account (let's say MSN for the purposes of the example) and will allow the client to communicate with the MSN account through our server. If the client loses it's connection (Ex: the browser crashes), the server should still hold the MSN connection until otherwise stated. Once the client comes back, the connection should be reestablished as if nothing had happened. Our current platform handles all of the communication (done via XML) between the client and the server. The issues that we currently are having is that we're unable to salably provide access to the IM protocols. Previously, we've used XMPP Transports with OpenFire's IM Gateway; however, that resulted in disaster. We'd like to obtain a highly scalable solution that we can deploy and have our servers communicate with. In the purest essence of the project, we're looking for a Restful API to the IM Protocols where we can utilize XM to tell the IM Server what to do. Please note that the server/client aspects of this project have already been handled, the point of mentioning them is just so the developer can obtain a better feel for the project at hand. The scope of this project is limited to providing a scalable solution that allows XML to be used to communicate with the IM protocols. We do not require full protocol support for each protocol. We only require the following: Sign On/Off Buddy List Events Send/Receive IMs Typing Notifications Buddy Icon Set/Retrieval Profile Set/Retrieval Alias Set/Retrieval Status Message Set/Retrieval (Away/Invisible) The above features must be implemented to allow the following accounts to work: AIM/.Mac (MobileMe)/ICQ/MSN/YIM If implemented correctly, this solution should be able to be run on Amazon EC2 instances and our platform should be able to run the API requests to handle the required connections. While the listed skill-sets are what we've identified as being most suitable for this project, we are very open to seeing other points of view on this. Our primary concern is to stay away from Java (as it's been proven to be very difficult to scale for our needs) and the .NET family of languages. However, if the arguments against this decision are fluid enough, we are open to new ideas.