Jacob,
Let's take a step back here. A service is a piece of functionality. The service must be implemened and EJB is a means to implement the service. This service can be consumed by
1. A
java consumer using ejb client jar over RMI-IIOP
2. Any consumer using web service client over SOAP-HTTP
If you expose something as a web service, it just means that the service can be invoked using SOAP/HTTP but the role of implementation doesn't go away. If you take the EJB out, who will execute the logic of the service?
If you are thinking EJB allows a client in a remote JVM to invoke a service, similarly, web service allows a remote client to invoke a service so you don't need EJB, you are right (and wrong). You don't need EJB from remote access perspective. You can use a POJO (Plain Old Java Object) and expose it as a web service and access it remotely. However, if you don't use EJB, you loose container provided functionality such as role based security, transactions etc. Also, plain java call runs faster than EJB runs faster than web service. So, for performance reasons you may decide to stick with EJB as opposed to web services.
Lately, alternative approaches like
servlet based web service and spring container supported POJO based web service are becoming popular. They don't suffer from some of the disadvantages of EJBs. On the other end of the spectrum there are also concepts like REST-ful services, which can use JSON format making the web service perform even better (JSON is an alternative to XML. It reduces the overhead of XML processing).
So, to summarize, EJB isn't needed from remote access perspective but they may be needed based on other requirements. Hope this helps...