EJB2.1 and Web Services?

[ajaquith]

I was leafing through the public draft of the EJB2.1 spec (part of J2EE 1.4) and saw a number of references to a new "web service" client type, in addition to the local and remote client types that are part of EJB2.0.

Looks interesting. The web service client interface would work with JAXP-RPC service endpoints, for stateless session EJBs. A sample deployment descriptor:


...
<ejb-name>InvestmentBean</ejb-name>
<ejb-class>com.wombat.empl.InvestmentBean</ejb-class>
...
<service-ref>

This is a reference to the stock quote
service used to estimate portfolio value.

<service-ref-name>service/StockQuoteService</service-
ref-name>
<service-ref-type>com.example.StockQuoteService
</service-ref-type>
</service-ref>
...


Clients would call the web service as follows:

public class InvestmentBean implements SessionBean {
public void checkPortfolio(...) {
...
// Obtain the default initial JNDI context.
Context initCtx = new InitialContext();
// Look up the stock quote service in the environment.
com.example.StockQuoteService sqs =
(com.example.StockQuoteService)initCtx.lookup(
"java:comp/env/service/StockQuoteService");
// Get the stub for the service endpoint
com.example.StockQuoteProvider sqp =
sqs.getStockQuoteProviderPort();
// Get a quote
float quotePrice = sqp.getLastTradePrice(...);
...
}
}

Dr. Jung, any thoughts on this? This looks like a great step forward for J2EE... I've got nothing against Apache Axis/SOAP per se (it works well enough), but this would seem to simplify things even more, and it's EJB-centric instead of servlet-centric.

[dward2]

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.

[jeffdelong]

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 =
(com.example.StockQuoteService)initCtx.lookup(
"java:comp/env/service/StockQuoteService");

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.

[dward2]

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.