EJB in Java EE 7 are lightweight. In fact the discussion and debate about heavyweight versus lightweight misses the point. Every software system that we now employ in our application will be almost certainly managed by a container. Whether that container is a CPU on a chip or a Java EE application server really is neither here nor there. What matters to most technicians and definitely to business is the ability for the components to be on scale on demand. Does the container infrastructure simplify the architecture? Does the container infrastructure overlap or conflict with another type of containerization? Think about it this way. How many layers of ingredients are you going to put on that pizza base? You and I would just like to enjoy a nice tasting pizza at the end of the day. It is this ability to mix and match that serves EJB in Java EE 7.

Lastly, to emphasize the point, observe the demand for poolable session EJB in application servers over time from 2002 to 2013:

Application servers in the cloud computing environment will be expected to pool over one million EJB instances and auto scale all of them. Now if that is not considered lightweight, I really do not know what is.

An EJB can serve as JAX-RS 2.0 endpoint (Chapter 8, RESTful Services JAX-RS 2.0):

@Path("/projects")
@Stateless
public class ProjectRESTServerEndpoint { /* ... */ }

An EJB can be WebSocket server-side endpoint (Chapter 7, Java API for HTML5WebSocket):

@ServerEndpoint("/sockets")
@Stateless
public class ProjectWebSocketEndpoint { /* ... */ }

An EJB can even be Java Servlet (Chapter 6, Java Servlets and Asynchronous Request-Response):

@WebServlet("/browse")
@Stateless
public class ProjectBrowse extends HttpServlet { /* ... */ }

Nonetheless, I strongly recommend that you continue to separate your concerns, your view from model-control logic. Please do not follow the previous example as good practice.