• 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

Using Static Variables in JAX-WS

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

I m new to this web service thing. I was wondering what will be its behaviour when you use static variables in a web service class. (Marked as @WebService). It seemd to be working fine but is that behaviour something we can rely on?

please help me
 
Ranch Hand
Posts: 111
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You implement webservice endpoints as a JAX-RPC service endpoint (which executes in the context of a servlet in the web container) and as a EJB stateless session bean endpoint. The implication of using a static variable for a webservice will thus depend on what type of service endpoint you develop your webservice as and that implication will be same as when you use the static variable in a servlet or a stateless session bean.

For a servlet using a single/multithread model, the static variables will still need to be synchronized on if they are not final. In EJBs, its okay to use a final static variable but a non-final static variable will not behave correctly as statless session bean states are not persisted across invocations.

So in short, its okay to use a final static variable but not a non-final static variable if you have an EJB endpoint. In case of servlets- based JSEs if you have non-final static variables then you will need to synchronize the access to the static vars.
 
Lahiru Abeydeera
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi

thanks for the reply!
i m using JAX-WS and as a web application. My basic requirement is to manage client session state. since it is not possible according to my knowledge i decided to use static variables. Is there a better way to do it. (Manageing client session) Can you expose a Stateful SB as a web service. I need my web service to be accessible from any client (/net/java/c++ etc..)


Regard
Lahiru

ScJP, SCBCD
 
Watsh Rajneesh
Ranch Hand
Posts: 111
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can implement service endpoint which support persisting the conversational state across multiple method calls. The strategy is to return the client a unique token and identify the persisted state information with the unique token. This can be done for both types of service endpoints (servlets based or ejb stateless session bean based). For ejb stateless session bean based endpoints you will need to persist the conversational state in some data store (primary key being the unique client token). For servlet based endpoint you can persist the session state information in the HttpSession object as an attribute identified by the unique client token. Read more here.
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Watsh Rajneesh:
For servlet based endpoint you can persist the session state information in the HttpSession object as an attribute identified by the unique client token.


Though that approach is usually not recommended as it can lead to interoperability problems as the session-maintenance requirements cannot be communicated through the WSDL. A (required) client token that is an explicit part of the SOAP message (a correlation identifier) is preferred. See more about that in this topic.

Chapter 3: Service Endpoint Design
3.4 Designing a Service�s Interaction Layer
3.4.1 Designing the Interface
3.4.1.1 Choice of the Interface Endpoint Type

Chapter 8: Application Architecture and Design
8.4 Web Service Communication Patterns
8.4.1 Correlating Messages
 
Lahiru Abeydeera
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanks guys

i really appreciate the support.

but i got to say something here. this javaranch forum is really cool. i tried this problem at sun java forums before and no one did reply yet.

thanks again for the support.
 
Watsh Rajneesh
Ranch Hand
Posts: 111
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Peer,

The HttpSession object will probably not work as a state storage, i agree, if there are intermediaries so we need some other store to persist the server side state information mapped to the session identifier even for a JSE. What is the recommended type of storage to use for storing state on server side?

Is there any difference in passing the session identifier (ie the unique client token) as web method params (in soap body) or passing it as correlation identifier (in soap header) - as WSDL can identify both ways.

Thanks,
Watsh
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic