Servlet endpoint Vs EJB endpoint

[Apratim Khandalkar]

Hi All,
I am reading Webservice endpoint from RMH book and only difference between Servlet endpoint and EJB endpoint is that it says using EJB endpoint we can take advantages of transaction management.
My question is servlet endpoint can also take advantage of transaction management ?
Is there any other difference between them? Please help

Thanks in advance
Apratim
SCJP 1.5
SCEA Part I
Mission SCJWS

[sajan sachin]

Hi,

I dont know how servlets can handle transaction management !!!
According to me servlets cant handle transaction by itself.
But anyways when compared to servlets in EJB transaction management is superior in EJB the transaction management is totally declarative.
You can declare transaction attributes in ejb-jar.xml
More over EJB container can handle transaction more effeciantly than we manually handle the transaction.

Thanks,
Sajan C

[Peer Reynders]

Originally posted by Apratim Khandalkar:
it says using EJB endpoint we can take advantages of transaction management.

The EJB can use transaction management for itself when it calls other EJBs - that doesn't mean that there is transaction management across the web service link using HTTP/SOAP.
In other words, when a web service client calls an EJB-based web service it calls it as a web service client - not an EJB client, so there is no propagation of EJB transactions from the client over the HTTP/SOAP link.

Support of web service transactions requires additional protocols (example) which do not necessarily integrate with EJB transactions. That means that the web service EJB starts and ends the transaction without involving the client. Furthermore two-phase commits are considered a form of tight-coupling with web services - usually compensation is considered more loosely coupled.
Your Coffee Shop Doesn�t Use Two-Phase Commit (PDF)

My question is servlet endpoint can also take advantage of transaction management ?

Not directly. But nothing is stopping the servlet from using an EJB that uses transaction management for itself which is all that an EJB based endpoint can do.
[ March 02, 2008: Message edited by: Peer Reynders ]

[Leo Blommers]

an other difference is that webservices based on servlets are session aware and webservices based on ejb's arent.

webservices based on ejb's can use declarative authorization, and servlets cant.

ejb's have better support for concurrent service calls (there will be ony 1 servlet to handle the service calls and there can be multiple instances of the ejb in a pool to handle the service calls)

together with the already mentioned declarative transactions of ejb's that makes the 4 major differences

[Apratim Khandalkar]

Hi All,
Thank you for your reply.But I am wondering how the non-java client might call EJB endpoint based webservice.
Please help

Thanks in Advance

Apratim
SCJP 1.5
SCEA Part I
Missin SCDJWS

[Peer Reynders]

Originally posted by Apratim Khandalkar:
But I am wondering how the non-java client might call EJB endpoint based webservice.

The point is that the client (java or non-java) calls the endpoint as a web service client (not as an ejb-client). To the client it makes no difference whether the endpoint is implemented as a servlet-based endpoint or an ejb-based endpoint. The ejb-based endpoint can take advantage of ejb features in its own processing and when it interacts with other parts of the application server - it cannot use ejb features in its interaction with the web services client. That also means that an ejb component that happens to be a web services client cannot expect its transactions and security credentials to propagate over the HTTP/SOAP link.

For example:

An ejb-based endpoint cannot use the "mandatory" EJB transaction attribute because there is no standard way for an existing EJB transaction to propagate from the web services client to the endpoint. If the SLSB is invoked by a web service client the EJB transaction attribute "NotSupported", "Never", or "Supports" won't start a transaction (i.e. there is no transaction); if the transaction attribute is "Required" or "RequiresNew" then a new transaction will be created.

See RMH page 673.
[ March 08, 2008: Message edited by: Peer Reynders ]

[Apratim Khandalkar]

Hi All,

Thanks a lot for your reply its much clear now

[Sam Powell]

Originally posted by Leo Blommers:
an other difference is that webservices based on servlets are session aware and webservices based on ejb's arent.

I am not sure if I get this correct, are you saying that the my service endpoint is capable of supporting sessions just because the servlets are used to implement the endpoint?
How is this different from saying that my endpoint is transaction aware because its implemented using EJB.
I am confused...
-Sam

[Peer Reynders]

Originally posted by Sam Powell:
Are you saying that the my service endpoint is capable of supporting sessions just because the servlets are used to implement the endpoint?

Yes - provided your web service client supports them. However the practice of using HTTP sessions in SOAP web services is strongly discouraged.

How is this different from saying that my endpoint is transaction aware because its implemented using EJB.

First of all because HTTP-Sessions and EJB transactions can't be compared on any level - apples and oranges - but I don't think that is what you actually meant.
Second, a web service client can use the HTTP-session over the HTTP link, while the web service client cannot propagate an EJB-transaction over the HTTP/SOAP link.

However you should never use HTTP-sessions in your web service implementation even if HTTP-sessions are supported.

Basic Profile 1.0

4.3.10 HTTP Cookies
The HTTP State Management Mechanism ("Cookies") allows the creation of stateful sessions between Web browsers and servers. Being designed for hypertext browsing, Cookies do not have well-defined semantics for Web services, and, because they are external to the SOAP Envelope, are not accommodated by either SOAP 1.1 or WSDL 1.1. However, there are situations where it may be necessary to use Cookies; e.g., for load balancing between servers, or for integration with legacy systems that use Cookies. For these reasons, the Profile limits the ways in which Cookies can be used, without completely disallowing them.

R1120 An INSTANCE MAY use the HTTP state mechanism ("Cookies").

R1122 An INSTANCE using Cookies SHOULD conform to RFC2965.

R1121 An INSTANCE SHOULD NOT require consumer support for Cookies in order to function correctly.

R1123 The value of the cookie MUST be considered to be opaque by the CONSUMER.

The Profile recommends that cookies not be required by instances for proper operation; they should be a hint, to be used for optimization, without materially affecting the execution of the Web service. However, they may be required in legacy integration and other exceptional use cases, so requiring them does not make an instance non-conformant. While Cookies thus may have meaning to the instance, they should not be used as an out-of-bound data channel between the instance and the consumer. Therefore, interpretation of Cookies is not allowed at all by the consumer - it is required to treat them as opaque (i.e., have no meaning to the consumer).

The main problem is that the SOAP envelope was designed to travel over intermediate nodes, sometimes travelling over multiple transports. What exactly are you going to do with your HTTP session ID (and session data) when the envelope arrives at the HTTP server and the server then wants to sent the envelope on to the next node over JMS? In fact the HTTP server may not know enough about what is going on to maintain a meaningful session. That is why SOAP web services are supposed to use correlation identifiers inside the SOAP envelope rather than a session ID in an HTTP header.

Ideally a web service should be stateless because storage of client state impairs scalabilty of the web service. Correlation identifiers are typically used to correlate messages that relate to the same "long running business transaction".
[ March 11, 2008: Message edited by: Peer Reynders ]