JSR 109: Web Services Inside of J2EE Apps
Well I guess its good that Servlets or EJBs can be used to create web services (well duh). Though maybe its time for a completely new web services container like Glue or Axis? EJB certainly seems like a sledgehammer to crack this web services nut.
The article certainly pushes EJB rather than Servlets as implementation technology for web services. I guess this is hardly suprising coming from a BEA employee; afterall there's plenty of free Servlet engines like Jetty or Tomcat together with good and cheap engines (unlike BEA). So if you work for BEA I guess you're bound to try push EJB for everything.
The table on page 2 seems kinda biased. Servlets scale badly whereas EJBs scale well? HUH? That doesn't seem to match my experience in the real world where scalable Java websites are typically built with Servlets and no EJBs. (e.g. E*TRADE). Also there's plenty of FUD like Servlets have a high startup time, have large memory footprint, are long lived and are marginally lifecycled.
J2EE has 2 application server models; servlets and EJBs and if I had to choose one it'd be servlets every time. Servlets are simpler, cleaner, meaner, cheap and scalable. It also seems to me to be a much better fit to web services, since it already understands HTTP nicely and doesn't have all the RMI, local/remote and EntityBean cruft of EJB.
Also I don't understand why a web service in JSR 109 cannot be implemented by a Servlet that doesn't implement the SingleThreadModel interface. If a servlet doesn't implement SingleThreadModel then just a single object is used for all requests - no need for pooling. Its wierd that JSR 109 can't benefit from this, since web services typically are stateless.
Its also disappointing that there's no support for Message Driven Beans. Incidentally if you ever feel like a lightweight Servlet equivalent of Message Driven EJBs, try the Message Driven Objects in the Messenger project.
9:45:05 AM
|