Actually, IMHO, AXIS in JBoss.net is what will provide most everthing that is needed for JBoss to be EJB 2.1 compatible (as related to web services). You still need the Axis Servlet (why do you think you wouldn't?), it's just that it appears we will be able to configure it via ejb-jar.xml instead of having to define the EJBProvider in web-service.xml.
The example client shows an in VM lookup of the stock quote service:
// Look up the stock quote service in the environment.
com.example.StockQuoteService sqs =
It is not clear why one would want to use a web service interface to an EJB when executing in the same JVM, and pay the high cost of the serialization. Why not just use the EJB's remote (or even better, local) interface?
Typical web services clients would be running on other machines, at other companies, possibly not even written in Java, and would need to access the service through a URL-based service endpoint (e.g., http://hostname:8080/axis/services/StockQuoteService), and hence through JBoss.NET and Axis.
I agree about the serialization when in the same vm, but you will be also able to bind an external service into a local (ie: java:comp/env) namespace via deployment descriptors, at which point it makes sense.