• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

web service - EJB or servlet based?

 
Ranch Hand
Posts: 165
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,

When designing a web service, which is better servlet-based or EJB-based?

At this time, I have one insert which will be handled by a page-lock by the database. This means I have no transaction management in my web service method. The clients will be within our firewall, but may or may not be java J2EE clients. Because these clients are within our firewall, security will not be an issue. We are using EE5 on CAPS 6u1. Our database is SQL server. I am using Toplink JPA to insert the row. We may also have a need to call the web service from a BPEL process. We also will have two other web services, one of which will need database transactions. Is it better to choose the same technology for all 3 and stay consistant? Also, the usage of this web service may grow substantially over time (isn't that everyone's hope).

I have searched javaranch for information on this subject, and am thinking that some of the threads may deal with older versions of J2EE when stateless sesssion beans were slower. Is EJB overkill for this?

Thanks for any help in this direction.

Ravi


 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In terms service-orientation using EJB-based web services goes against the Contract Centralization Pattern and introduces the increased danger of contract-to-implementation and possibly contract-to-technology coupling. EJB still is a component technology so there is the increased danger of treating the SLSBs as such - rather than as services.

Often development convenience (i.e. EJB supports "all this" out of the box) comes at a cost that may only become apparent later when it is too late, so what initially seemed to support the requirements may in fact become a constraint. A lot of service design decisions aren't clear cut and depend on a lot of different factors. It is probably a good idea to only use EJB-based services when you have a very good reason to use them - probably better to stay with "pure services" that aren't constrained by the technology that is used to implement them.
 
Ravi Danum
Ranch Hand
Posts: 165
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Peer,

Thank you so much for this valuable information. I will read these links. This is great design information.

As always, your help is so appreciated.

Ravi
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
See this post for comments regarding the issue of contract-last development - EJB-based web services tend to be developed as "SLSB with web service annotations".
 
Ravi Danum
Ranch Hand
Posts: 165
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Peer,

This is a great link. I will read this slowly later on and will base my design on this information.

I hope the Javaranchers know they are lucky to have your insite, knowledge, and patience!

Kind regards.

Ravi
 
Ravi Danum
Ranch Hand
Posts: 165
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Peer,

I have looked at the links you sent.

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?

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?

Your insight and knowledge is always appreciated.

-Ravi



danger of contract-to-implementation and possibly contract-to-technology
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Ravi Danum
Ranch Hand
Posts: 165
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Peer,

Once again thank you for the new and valuable information.

Question: I thought that the WSDL binding to SOAP, eg: <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> meant that the service would use the HTTP, SOAP XML protocol, even if the web service was based on an EJB. In the EJB web service case, is the protocol HTTP, SOAP, XML or RMI-IIOP?

Thank you again.

Ravi

p.s. The Compensating Service Transaction is very interesting...its helpful to have an alternative to the transaction where resources are locked until completing.
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ravi Danum wrote:In the EJB web service case, is the protocol HTTP, SOAP, XML or RMI-IIOP?


  • {HTTP, SOAP, XML} when being accessed as a SOAP web service
  • RMI-IIOP when being accessed as an EJB

  • The contract centralization pattern basically makes sure that the web service contract maintains its significance and avoids constraining the evolution of the service because of component clients which have formed tightly coupled dependencies on implementation or technology details typically exposed through a component interface.

    Potential problem areas for simultaneous support of a web service contract and component interface:
  • Objects can support arbitrary object graphs, potentially containing cycles. XML on the other hand is hierarchical in nature.
  • Objects make use of inheritance and polymorphism. While XML officially supports inheritance and polymorphism, its support on different platforms can vary.
  • XML supports restriction - basically a form of specialization that differs from inheritance. Objects don't really have a good equivalent.

  • etc.

    Effective Enterprise Java. Chapter 5: State Management (PDF) Item 43: Recognize the object-hierarchical impedance mismatch (Page 249)
     
    Ravi Danum
    Ranch Hand
    Posts: 165
    1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Thanks Peer. This chapter is very helpful. I am so glad to get this information during the design phase of our web services. You've provided so many valuable references and insight which is greatly appreciated.

    -Ravi
     
    Author
    Posts: 3473
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Also look at the Spring Web Services document. Spring supports contract-first approach.

    http://static.springsource.org/spring-ws/sites/1.5/reference/html/why-contract-first.html
     
    Ravi Danum
    Ranch Hand
    Posts: 165
    1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Arulk,

    This article is helpful also. I will include a new section in my design document with this type of information.

    Many thanks.

    Ravi
     
    Consider Paul's rocket mass heater.
    reply
      Bookmark Topic Watch Topic
    • New Topic