WebService and ConversationId

[mheidt]

Hello,

I tried to follow seam-bay but to no avail.

jboss-seam-2.0.2.CR1

@Stateless
@WebService(name="TSCMService", serviceName="TSCMService")
public class TSCMGate implements TSCMGateRemote {
  @WebMethod
  public boolean logout() {
    identity.instance().logout();
    return !Identity.instance().isLoggedIn();
  }

  @WebMethod
  public boolean testLogin() {
    return Identity.instance().isLoggedIn();
  }
}

I was putting the standard-jaxws-endpoint-config.xml into the META-INF of the ejb - in parallel to the ejb-jar etc.

<jaxws-config xmlns="urn:jboss:jaxws-config:2.0" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xmlns:javaee="http://java.sun.com/xml/ns/javaee"
      xsi:schemaLocation="urn:jboss:jaxws-config:2.0 jaxws-config_2_0.xsd">
   <endpoint-config>
      <config-name>Seam WebService Endpoint</config-name>
      <pre-handler-chains>
         <javaee:handler-chain>
            <javaee:protocol-bindings>##SOAP11_HTTP</javaee:protocol-bindings>
            <javaee:handler>
               <javaee:handler-name>SOAP Request Handler</javaee:handler-name>
               <javaee:handler-class>org.jboss.seam.webservice.SOAPRequestHandler</javaee:handler-class>
            </javaee:handler>
         </javaee:handler-chain>
      </pre-handler-chains>
   </endpoint-config>
</jaxws-config>

For Testing I was using the Web Services Explorer of  Eclipse.

login works and delivers:

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
  <env:Header>
    <seam:conversationId xmlns:seam="http://www.jboss.org/seam/webservice">3</seam:conversationId> 
  </env:Header>
 <env:Body>
   <loginResponse xmlns:ns2="http://gate.ws.dante_tscm.dai.com/">
    <return>true</return> 
   </loginResponse>
  </env:Body>
</env:Envelope>

Now I thought, I just need to take the conversionId and call a request like

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:q0="http://gate.ws.dante_tscm.dai.com/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <soapenv:Header>
  <seam:conversationId xmlns:seam="http://www.jboss.org/seam/webservice">3</seam:conversationId> 
  </soapenv:Header>
 <soapenv:Body>
  <q0:testLogin /> 
  </soapenv:Body>
  </soapenv:Envelope>

But this returns false with a new conversionId of 4

Any help is really appreciated!

[ajamtli]

You have to maintain the session between the two web service requests.

In Java you can do something like this:

bindingProvider.getRequestContext().put(BindingProvider.SESSION_MAINTAIN_PROPERTY, true);

[shane.bryzak]

You need to actually be in a long running conversation for the conversation ID to mean anything.

[maheidt]

Thanks Shane,

But letting the service call the following doesn't work either:

@Scope(ScopeType.CONVERSATION)
@Name("tscmGateSession")
public class TSCMGateSessionBean implements TSCMGateSession{

     @Begin
     public boolean login(String username, String password) {
          Identity.instance().setUsername(username);
          Identity.instance().setPassword(password);
          Identity.instance().login();
          return Identity.instance().isLoggedIn();
     }
     
     public boolean testLogin() {
          return Identity.instance().isLoggedIn();
     }

}

[shane.bryzak]

Are you maintaining the same session between requests, as Anders pointed out?

[maheidt]

I'm not quite sure how to do it.

In my understanding soap-webservices are about transfering text messages.
I have two kinds of clients to test the server with.

First the Web Service Explorer of the JBoss Developer Studio (Eclipse Europe)

And second a client generated from the wsdl. The generated proxy of the client doesn't deliver any function calls like bindingProvider or RequestContext.

So I expect something in the server code or something like the conversionID in the soap-header to fix this.

[shane.bryzak]

Conversations only exist within the scope of a session, so you definitely need to be maintaining the session ID between requests.  Most web service clients (as far as I'm aware) allow you to maintain the session - I haven't used the Web Service Explorer in Eclipse so I don't know if it supports this, but if you are actually writing a client to consume web services in Seam then you'll most likely be using something like JBossWS or Apache Axis, both of which I'm certain support propagation of the session ID.

[shane.bryzak]

Oh and just to clarify, yes SOAP-based web services are about transferring text messages, however this is done within the context of an HTTP request which contains a number of header values (including cookies that contain the session ID) as well as the SOAP request.

[maheidt]

Ok, I needed to change the generated Axis-Client code:

XYZBindingStub.createCall:

_call.setMaintainSession(true);

And the Web Service Explorer doesn't seem to support it...

[maheidt]

Better is to put the following to each function you want the session to be maintained:

_call.setProperty(org.apache.axis.client.Call.SESSION_MAINTAIN_PROPERTY, Boolean.TRUE);

[maheidt]

But actually this can't be the solution.
Everytime I need to regenerate the client proxy, I need to change the  stub manually?!

So isn't there anything like a parameter to @WebMethod or another parallel annotation which would do this?

[shane.bryzak]

Does the code have to go in the stub?  There's no annotation or other parameter that will tell your client to maintain sessions.

[ajamtli]

Have a look at the
Metro Users Guide for more information about writing web service clients. Section 5.3 talks about HTTP Cookies and the
SESSION_MAINTAIN_PROPERTY.

[mheidt]

Yes, it's on the client stub.

And yes, I think it's just one of the missing links in the WS specification...(i don't have a clue about the ws specification...)

I could imagine an annotation which would bypass the client-site properties...but those need to be stored in the WSDL which doesn't seam to be specified.

Renaming the name of the parameters or functions itself is just not enough :)

In my point of view the client stub needs to be generated fully automatically, in order to have a nice solution.