Ravi Danum wrote:I can see that an EJB web service would violate the Contract Centralization design pattern because an EJB could expose more than just the service endpoints (for example other public methods that the client could call). This would allow the user to sometimes be communicating over SOAP/HTTP and other times over RMI/IIOP. Is this a correct assessment?
It has less to do with the fact that the
same user can use both interfaces but with different sets of users forming different types of dependencies on it. Ultimately each interfacing technology has different limitations. There may be directions where a web service interface could evolve towards that has no equivalent in EJB. So the EJB interface could
unnecessarily constrain the evolution of the web service interface. Also component-based interfaces tend to promote tight coupling of the client to the underlying service logic - because of these established dependencies the evolution of the service is severely constrained even if the web service interface was designed with loose coupling in mind.
How does an EJB web service violate contract-to-implementation coupling and contract-to-technology coupling? Do you have examples of this? Do these refer to the possibility that the EJB web service could be created using java2wsdl?
Contract-to-technology coupling results from the use of "proprietary" communication protocols. EJB uses
RMI-IIOP which is decidedly Java-centric. So EJB client's suffer from contract-to-technology coupling due to EJB's use of the "non-open" RMI-IIOP protocol. Web services use open-standard communication technology (HTTP, XML,
SOAP, etc.) so the clients aren't technology coupled (as there are no obstacles to adopting these technologies). So web service clients don't suffer from contract-to-technology coupling (as long as no-one sneeks anything platform specific into the interface).
Java2WSDL leads to contract-to-implementation (and more importantly contract-to-logic) coupling but this is really an issue with both POJO and EJB-based web services - ultimately the Java-ness of the code is going to leak into the web service interface. It is possible to create EJB-based web services contract-first - however ultimately the web service contract also has to translate to an EJB interface which can place additional constraints on the web service contract - constraints that a non-EJB based web service does not have to observe.
Somebody is ultimately going to bring up "transactions". However what many component developers do not realize is that "two phase commit" (2PC) is a form of tight coupling. Using 2PC in the same service inventory may be workable, however once collaborating services belong to inventories that are under the control of different owners, 2PC becomes more difficult. Also 2PC makes no sense for "long-running" transactions. In many cases services have to be prepared to implement compensation (the loosely-coupled alternative) instead (
Your Coffee Shop Doesn’t Use Two-Phase Commit (PDF) and EJB-technology doesn't help with that.
Compensating Service Transaction
Atomic Service Transaction