aspose file tools*
The moose likes Web Services and the fly likes JAX-WS Servlets and Stateless Beans Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Web Services
Bookmark "JAX-WS Servlets and Stateless Beans" Watch "JAX-WS Servlets and Stateless Beans" New topic
Author

JAX-WS Servlets and Stateless Beans

Al Purvis
Greenhorn

Joined: May 23, 2006
Posts: 22
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


Al<br />(SCJP,SCJD and working on SCEA)
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
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

Joined: May 23, 2006
Posts: 22
Thanks
Anthony Karta
Ranch Hand

Joined: Aug 09, 2004
Posts: 342
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


SCJP 5
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
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

Joined: Nov 17, 2008
Posts: 2
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

Joined: Aug 19, 2005
Posts: 2922
    
    5
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.

  •  
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: JAX-WS Servlets and Stateless Beans