|
Problem(Abstract) |
These APIs are NOT available for IBM® WebSphere®
Application Server versions 5.0 and 5.1. Service Endpoint Implementation
enables users to make several calls with one reference using same client
proxy, but they can not reconnect easily to that session later through
another invocation by means of cookie without using a reference to the
same stub, as would be the case using newer TransportHeader APIs to set a
cookie in the request header.
General Information:
Cookies are part of or more correctly synonymous with the http protocol
and are expected to be created
as part of the Java™ 2 Platform, Enterprise Edition (J2EE) specs. However,
the creation of a cookie occurs only by explicit direction of the client
to the web container. Please see the API
HttpServletRequest.getSession(boolean create).
If create is set to false by the client then no cookie will be created by
the web container.
The relevant J2EE APIs to create and destroy sessions are listed under
interfaces HttpServletRequest and HttpSession.
Session cookies are information transmitted between the client and a web
container. The J2EE expose APIs to get at the cookies through
HttpServletRepsonse.getCookies() API and also
HttpServletRequest.getHeaders().
Thread services is part of the web container provisions. The web container
thread pool is configurable. But unless the threadpool is set to one it is
not possible to guarantee that the same thread will serve multiple
independent requests. So it is not necessarily possible to avoid using
different threads and cookies from new or different client-service
invocations or stubs.
Servlet Container and Service Endpoint Implementation:
Using Web Service runtime and Java API for XML-based Remote Procedure Call
(JAX-RPC)
you can implement something like this to acquire sessionID:
HttpSession session= jaxrpcContext.getHttpSession();
mySessionId = session.getId()
.
http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/http/HttpSession.html#getId()
The following developer article contains overview instruction to build
stateful sessions in JAX-RPC application client using serviceendpoint
model to exploit session support offered by servlet container when
combined with special stub property:
Build stateful sessions in JAX-RPC applications:
http://www-128.ibm.com/developerworks/xml/library/ws-tip-stateful.html
*Problem is that most of the jax-rpc servlet endpoint implementations
assume that the client will make several calls with one reference with a
web service client proxy. However, there are cases where the client needs
to reconnect to a session by means of a cookie. The cookie could also be
used for proprietary business information, perhaps sending a security
token over.
A user can programmatically configure his JAX-RPC client so that it sends
the Cookie header to maintain session with the web service (assuming that
the service is configured for sessions), but this assumes you keep a
reference to the stub and always communicate with this same stub.
At http://java.sun.com/j2ee/1.4/docs/api/javax/xml/rpc/Stub.html#SESSION_MAINTAIN_PROPERTY
is this snippet of Java documentation:
<snippet>
SESSION_MAINTAIN_PROPERTY
public static final String SESSION_MAINTAIN_PROPERTY
Standard property: This boolean property is used by a service client Page
25 of 32 to indicate whether or not it wants to participate in a session
with a service endpoint. If this property is set to true, the service
client indicates that it wants the session to be maintained. If set to
false, the session is not maintained. The default value for this property
is false.
Type: java.lang.Boolean
</snippet>
Remember, this only applies to a JAX-RPC client.
For example, application client code might look something like,
...
((javax.xml.rpc.Stub)stub)._setProperty(SESSION_MAINTAIN_PROPERTY,Boolean.TRUE);
Page 26 of 32
stub.helloWorld();
...
Where the stub object is an instance of the client-side implementation of
the service endpoint interface. In the case of a JAX-RPC client running in
the Application Server environment, this is the WSDL2Java-generated class
that extends com.ibm.ws.webservices.engine.client.Stub.
Implementing extensions to the JAX-RPC and Web Services for J2EE client
programming models:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/twbs_extendpm.html
Set the REQUEST_TRANSPORT_PROPERTIES and RESPONSE_TRANSPORT_PROPERTIES
properties in a JAX-RPC client Stub to enable a Web services client to
send or retrieve HTTP transport headers.
Generic Construct for New TransportHeader API:
Stub stub = (Stub) service;
HashMap requestTransportHeaders=new HashMap();
requestTransportHeaders.put("Cookie", "Some Cookie");
((Stub) service)._setProperty(Constants.REQUEST_TRANSPORT_PROPERTIES,
requestTransportHeaders);
Usage Case for New TransportHeaders:
JAX-RPC WebSphere Application Server 6.1 (or J2EE 1.4 spec equivalent)
generated proxy
Session id passed in from higher up, same with security token.
RemoteEmployeeServiceServiceLocator locator = new
RemoteEmployeeServiceServiceLocator();
RemoteEmployeeService service = locator.getRemoteEmployeeService(new
URL(endPoint));
Stub stub = (Stub) service;
HashMap requestTransportHeaders=new HashMap();
requestTransportHeaders.put("Cookie", "JSESSIONID=0000" + sessionId +
":-1; path=/");
requestTransportHeaders.put("Cookie", "TOKEN=? + token + ?-1; path=?);
((Stub) service)._setProperty(Constants.REQUEST_TRANSPORT_PROPERTIES,
requestTransportHeaders);
EmployeeInfo empInfo = service.getEmployeeInfo(?123?);
This is essentially stateless on the client, and can connect with any
session on the backend, in addition it passes a custom business security
token. |
|
|
|
Cause |
Request and Response TransportHeader APIs NOT available in
Application Server version 5.0 or 5.1. |
|
|
Resolving the
problem |
Migrate to Application Server version 6.0 or find a
programmatic workaround. |
|
|
|
|
Cross Reference information |
Segment |
Product |
Component |
Platform |
Version |
Edition |
Application Servers |
Runtimes for Java Technology |
Java SDK |
|
|
|
|
|
|