Can you explain how to deploy Java Beans or Java Components on an Internet Information Server?
There are many strategies for doing this. You aren't going to want to try to deploy Java directly in IIS, but through an intermediary, for example, a servlet engine.
Apache's Tomcat (http://jakarta.apache.org) support servlets and JSP and servlets. On the Jakarta Tomcat site you should be able to get a plugin that will allow IIS to forward requests to Tomcat via ISAPI. Even better, Tomcat is available for free, with source.
At this point, you will need to write servlets (and optionally JSP) that field the HTTP requests and delegate to your Java components and Java Beans. Don't worry, servlets are exceedingly simple to write if you are fairly comfortable with Java. More information on the Servlet API is available at http://java.sun.com/products/servlets/.
A nice pattern to use for your app is to field HTTP requests with your servlet (controller), delegate to your business objects and components (model), then forward to a JSP for display (view). This is a very common model/view/controller-like usage pattern for a Web application in Java.
For more information on JSP, go to http://java.sun.com/products/jsp/. In short, JSP serves as the view for your MVC application. JSP provides the ability to write HTML-embedded code and custom tags, much in the spirit of ASP. Defintely check JSP be out, but be warned, when writing the JSPs, keep them lean: minimize the embedded code, favoring custom tags and make sure they ONLY contain display logic. If you start crowding your JSPs with application logic, you will have a maintainence headache down the road. Other Web scripting languages like WebMacro (http://www.webmacro.org) can be an alternative to JSP.
Finally, you could use a RPC mechanism of some sort to forward requests to your Java components. For example you could use XML-RPC or SOAP from your IIS code. This would mitigate the need for a servlet engine.
Which strategy you need just depends on what IIS-features you want to use. If they are few, I would consider the servlet engine, otherwise try an RPC mechanism.