Why make an EJB rather than a Web Service?

I would have thought that there is a lot of information out there on this, but I haven't found anything that really answers my qu开发者_如何转开发estion.

What are the advantages of making an EJB rather than a web service? The only clear advantage I can come up with is performance. Even so, I can't find any hard data on how much more efficient EJBs are.

With web services, I can think of plenty of advantages including interoperability between java/.net and easier networking over firewall/proxies because it uses http. With the newer standards like WS-ReliableMessaging, WS-AtomicTransactions, MTOM, etc (which are suppose to be fully tested for interoperability between Sun & MS), what do EJBs offer that web services don't?

I've never worked with anything other than basic web services so maybe someone with experience with the more advanced web services standards could tell me that it all doesn't work as well as the vendors claim?

---

First, EJBs and WebServices are not exclusive alternatives, it's actually quite reaonable to create an EJB and have it expose both IIOP and Web Service interfaces.

So there are two questions here:

1. What's a good implmentation technology for a reusable piece of business logic.
2. Which invocation style to use for a piece of business logic? Considerations such as when is RMI/IIOP a good choice? When is SOAP/HTTP? When SOAP/JMS ... etc.

Writing EJB3 EJBs is pretty easy, and gives benefits such as transactionality, security, instance pooling and and managed, scalable infrastructure - this tends to pay off for serious enterprise logic. (you can also look at other frameworks such as Spring as an alternative.)

Now as to invocation style. Clearly, when inter-op with (say) .NET is needed then Web Services are useful. But, in a pure Java world, especially when Logic and "client" can be deployed in the same JVM, then using Local EJB interfaces will indeed be more performant than Web Services. When invoking remotely the performance comparison between RMI/IIOP and Web Services is not quite so clear cut, in some cases Web Services actually do quite well. For me the counter argument to using Web Services is that there have historically been many interop issues, version skew of standards between different vendors has been a problem - though if you're doing interop then I guess you will always have those kinds of issue.

---

Service Access If you want to support non-Java consumer of a java service then use web-service. For Java consumer, IIOP could be a choice.

Service Implementation If you want a container provided functionality such as transactions management then use EJB to implement service.

---

I don't want to be sarcastic, but most EJB implementations I saw prior to EJB 3 seemed to be designed to keep job security. That's my anecdote, for what it's worth.