Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

JAX-WS Servlets and Stateless Beans

 
Al Purvis
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

I do not not much about JAX-WS so please excuse this question. Can it used to implement both servlet and session bean webservices?

Thanks
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Both are supported under JAX-WS
Servlet-based example The Java EE 5 Tutorial: Creating a Simple Web Service and Client with JAX-WS
SLSB example: The Java EE 5 Tutorial: A Web Service Example: helloservice

Though the is something to be said for implementing the service as a POJO and then exposing it separately though a SLSB or Servlet-based WS endpoint (adapter). That way the EJB adapter can deal with "all things EJB" and the WS endpoint adapter can deal with "all things WS-*" and the service can concentrate on its own work (separation of concerns). SLSB based WS endpoints may be convenient but tend to be less flexible than servlet based endpoints.
 
Al Purvis
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks
 
Anthony Karta
Ranch Hand
Posts: 342
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Peer Reynders:
Both are supported under JAX-WS

SLSB example: The Java EE 5 Tutorial: A Web Service Example: helloservice

Though the is something to be said for implementing the service as a POJO and then exposing it separately though a SLSB or Servlet-based WS endpoint (adapter). That way the EJB adapter can deal with "all things EJB" and the WS endpoint adapter can deal with "all things WS-*" and the service can concentrate on its own work (separation of concerns). SLSB based WS endpoints may be convenient but tend to be less flexible than servlet based endpoints.


First of all, sorry to open this old thread but I got very basic questions:

1. Why endpoint class (ejb class) must be StateLess?

2. I don't understand this statement (from quote above) "and the WS endpoint adapter can deal with "all things WS-*"

thanks in advance
ak
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Anthony Karta:
1. Why endpoint class (ejb class) must be StateLess?


SFSB and servlets handle client specific data in totally different ways. Theoretically a SOAP web service could utilize client-specific information in a cookie-based http-session but that information is part of the HTTP request/response and is not stored inside the SOAP envelope - therefore that approach is deprecated and strongly discouraged (SOAP is supposed to be able to travel over more than one node and there is no guarantee the each hop will use HTTP). In SOAP client specific information is supposed to be either included in the envelope or referenced through a correlation identifier that is part of the information inside the SOAP envelope. Furthermore stateful web services do not scale well. Therefore it makes sense to limit EJB endpoint classes to SLSBs.

Originally posted by Anthony Karta:
2. I don't understand this statement (from quote above) "and the WS endpoint adapter can deal with "all things WS-*"


Basically EJB and SOAP web services are totally different beasts. The main reason for using EJB, security and transaction doesn't map at all that well to SOAP web services which have their own WS-* protocols for these features which are based on totally different assumptions. So if you need to share functionality between an EJB and a web service endpoint it makes sense to break things up to a common POJO, an EJB for utilizing EJB security and transactions and a web service adapter that translates WS-Security and (compensating) transactions.
 
chin desai
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Peer Reynders:


Basically EJB and SOAP web services are totally different beasts. The main reason for using EJB, security and transaction doesn't map at all that well to SOAP web services which have their own WS-* protocols for these features which are based on totally different assumptions. So if you need to share functionality between an EJB and a web service endpoint it makes sense to break things up to a common POJO, an EJB for utilizing EJB security and transactions and a web service adapter that translates WS-Security and (compensating) transactions.


I am trying to expose some of my Session bean methods as Web services. Some of these methods return entity beans POJO as return type. I found this thread helpful in achieving my goal, but I got confused in common POJO creation. Does that mean that I should create a separate POJO similar to my entity bean and use that in my web services?

Thanks
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by chin desai:
Does that mean that I should create a separate POJO similar to my entity bean and use that in my web services?


This isn't a recipe approach but merely a collection of options that you may or may not be able to use. You can only go this route if you (can) exercise the appropriate separation of concerns. Usually enterprise beans are used for security and transaction support. If those features are used in a declarative manner you may have an opportunity to extract the business logic into a POJO (Refactoring: extract class). So at this point you would have
  • A session bean wrapper that the transaction and security support is configured against. However all business decisions are delegated to the business logic POJO.
  • The business logic POJO that has no idea how transactions and security are implemented. This POJO can now be tested with JUnit.


  • Now that you have the business logic POJO you can build a web service wrapper around it(s interface).
  • Just like the session bean business decisions are delegated to the POJO.
  • The web service wrapper can implement security with WS-Security (if required).
  • If you map external web services usernames to internal usernames/roles you could delegate to a declaratively secured bean after performing the mapping - however other type of declarations on the same bean may interfere with this solution.
  • The web service wrapper can implement transaction support with WS-BusinessActivity or WS-AtomicTransaction (if required). Note however that loosely coupled systems prefer compensation (Your Coffee Shop Doesn�t Use Two-Phase Commit (PDF)) over Two Phase Commit (2PC) - the notion of compensation will affect the business logic.

  •  
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic